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ABSTRACT 


This  study  uses  core  elements  of  the  system-of-systems  (SoS)  engineering  process  to 
obtain  lessons  learned,  which  are  then  used  to  recommend  process  and  organizational 
changes  to  facilitate  an  SoS  approach  to  current  and  future  U.S.  Army  acquisitions.  The 
study  finds  that  an  SoS  approach  is  necessary  to  accommodate  the  capability-based 
process  that  drives  the  Army  acquisition  system.  Recommendations  include  incorporating 
SoS  engineers  in  the  Joint  Capabilities  Integration  Development  System  process  to  build 
and  standardize  SoS  architectures;  using  a  chief  integration  officer  throughout  the  SoS 
life  cycle  to  provide  expertise  on  integration  and  interoperability;  and  establishing 
guidelines  for  integrated  product  teams  and  lead  system  integrators.  The  SoS  acquisition 
approach  will  also  benefit  from  capability  portfolio  managers  using  consolidated  funding 
as  opposed  to  the  current  stove-piped  funding.  The  SoS  wave  model  can  be  incorporated 
in  the  operation  and  support  phase  to  support  iterative  SoS  evolution.  The  Anny 
acknowledges  that  many  current  systems  are,  or  have  the  potential  to  be,  part  of  an  SoS 
environment;  however,  the  current  acquisition  processes  and  organizational  structure  are 
based  on  stand-alone  system  acquisitions.  The  recommendations  of  this  study  describe 
how  the  Army  can  support  SoS  acquisition. 
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EXECUTIVE  SUMMARY 


The  Army  acquisition  process  is  tailored  to  specify,  develop,  and  acquire  individual 
systems.  This  is  evident  in  the  policies,  processes,  and  organizational  structure  of  the 
acquisition  workforce.  Systems  engineering  is  often  found  in  Anny  policy  and 
acquisition  guidelines,  but  system-of-systems  (SoS)  engineering  is  not.  This  study 
detennined  that,  based  on  the  increasing  need  for  systems  to  be  interoperable  with  one 
another,  an  SoS  approach  to  acquisitions  is  more  suitable  for  current  and  future 
acquisition  programs.  This  study  used  core  elements  of  SoS  engineering  to  analyze  past 
Army  SoS  acquisition  efforts,  and  used  the  lessons  learned  to  recommend  process  and 
organizational  changes  that  would  enable  the  Army  to  go  from  a  systems  approach  to  an 
SoS-based  approach  for  future  acquisitions.  The  main  process  change  recommendations 
are  that  the  Army  should: 


•  utilize  DODAF  for  current  and  future  Anny  acquisitions,  and  apply  DODAF 
to  document  the  SoS  architecture. 

•  formally  incorporate  a  Department  of  Defense  Architecture  Framework 
(DODAF)  high-level  operational  concept  graphic(OV-l)  for  SoS  concept  of 
operations  (CONOPS)  development  and  consider  adding  other  DODAF 
models  as  mandatory  model  requirements  for  the  acquisition  process; 

•  mandate  that  private  firms  demonstrate  the  ability  for  technology 
developments  to  integrate  with  an  existing  or  future  SoS — further,  the  Army 
should  reward  private  firms  that  demonstrate  innovative  ways  to  use 
technologies  to  integrate  existing  or  future  systems  into  an  SoS; 

•  initially  allocate  funding  at  the  SoS  level,  and  divide  up  funding  into 
constituent  systems  based  on  each  system’s  objectives  during  an  SoS 
acquisition; 

•  simultaneously  test  as  many  SoS  constituent  systems  as  feasible  during  the 
system  development  and  demonstration  phase  and  clearly  state  assumptions 
used  during  testing — these  assumptions  must  be  clearly  articulated  in  the  test 
plan,  and  the  test  plan  also  must  describe  the  impacts  to  the  system  if  the 
assumptions  do  not  hold  true; 


xvii 


•  have  the  program  manager  (PM)  evaluation  process  emphasize  the  PM’s 
efforts  to  integrate  his  or  her  program  into  its  SoS  framework;  and 

•  use  the  SoS  wave  model  as  an  assessment  tool  for  SoS  architectural  evolutions 
and  future  SoS  updates. 

This  study  found  that  some  of  the  organizational  changes  that  could  be 
incorporated  are: 

•  The  Anny  should  train  and  designate  SoS  engineers  as  mandatory 
stakeholders  in  the  Joint  Capabilities  Integration  Development  System 
(JCIDS)  process  for  Anny  acquisitions. 

•  A  Chief  Interoperability  Officer  can  be  assigned  to  all  future  Army 
acquisitions  early  in  the  process.  This  officer  will  be  the  authority  on  all 
interoperability  issues,  and  ensure  that  interoperability  objectives  are  met  in 
the  JCIDS  process. 

•  The  Anny  can  train  personnel  in  order  to  make  the  organizational  role  of  Lead 
System  Integrator  LSI  a  government  function,  or  at  a  minimum  oversee 
private  companies  that  assume  this  role. 

•  Capability  portfolio  managers  can  be  assigned  at  the  PEO  level,  and  current 
and  future  SoS  acquisitions  can  be  organized  based  on  the  capability 
manager’s  area  of  responsibility  as  opposed  to  the  program  executive  officer 
(PEO’s). 

The  study  concludes  by  discussing  additional  research  that  can  be  conducted  in 
the  areas  of  SoS  engineering  and  Army  acquisition. 
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I.  INTRODUCTION 


The  Department  of  Defense  (DOD)  acquisition  process  has  changed  several  times 
over  the  past  fifty  years  (Fox  2012).  According  to  Fox,  it  was  not  until  1960  that  the 
DOD  actually  adopted  a  formal  acquisition  strategy.  From  1966  to  2001,  there  have  been 
over  sixty  acquisition  reform  initiatives  attempting  to  solve  the  complex  issues  that  are 
characteristic  of  the  DOD  acquisition  process  (Fox  2012).  These  reforms  have  led  to 
some  improvements,  but  the  acquisition  process  still  faces  many  challenges  in  balancing 
cost  and  schedule  efficiency  while  maximizing  the  capability  gained  from  system 
development. 

During  the  early  1990s,  the  acquisition  strategy  used  a  threat-based  approach 
(Dickerson  2014).  Decision  makers  analyzed  current  and  future  threats  and  developed 
systems  designed  specifically  to  counter  these  threats  (Dickerson  2014).  Looking  at  the 
conflicts  in  which  the  United  States  was  involved  during  the  1990s,  one  can  see  the 
variety  of  potential  threats  the  United  States  had  to  mitigate.  For  example,  although  the 
Cold  War  was  coming  to  a  close  in  1990,  the  Russian  threat  was  not  completely 
eliminated.  Desert  Storm  was  taking  place  in  the  early  1990s,  as  well  as  conflicts  in 
Bosnia/Kosovo,  Somalia,  and  Afghanistan.  As  threats  evolved,  acquisition  systems 
became  bigger  and  more  complex  in  order  to  counter  a  variety  of  threats  from  different 
nations  in  different  environments.  Major  defense  acquisition  programs  (MDAPs),  which 
are  programs  that  exceed  a  certain  cost  threshold,  became  commonplace.  These  systems’ 
total  operating  costs  typically  range  from  the  hundreds  of  millions  to  billons,  and  often 
take  years  to  develop. 

In  2003,  the  DOD  established  the  Joint  Capabilities  Integration  and  Development 
System  (JCIDS),  which  represented  a  shift  in  acquisition  strategy  from  threat-based  to 
capability-based  (Fox  2012).  This  process  replaced  the  outputs  from  a  requirements- 
based  analysis — the  operational  requirements  document  and  mission  need  statements — 
with  the  initial  capability  document  and  capability  production  document,  with  output 
based  on  a  capability  analysis.  The  JCIDS  process  requires  sponsors,  usually  Combatant 

Commanders,  to  take  guidance  given  in  several  strategic  guidance  documents,  such  as  the 
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National  Security  Strategy  (NSS),  the  National  Strategy  for  Homeland  Security,  the 
National  Defense  Strategy,  and  the  National  Military  Strategy  (DOD  2015).  The  Joint 
Requirements  Oversight  Council  (JROC)  reviews  these  capabilities,  and  decides  whether 
or  not  a  materiel  or  non-materiel  solution  is  needed.  A  materiel  solution  consists  of  a 
physical  object  or  objects  that  form  a  system.  A  non-materiel  solution  consists  of  a 
change  in  policy  or  training  that  could  achieve  the  capability.  If  a  materiel  solution  is 
needed,  then  the  defense  acquisition  process  begins.  The  diagram  in  Figure  1  illustrates 
the  major  systems  in  the  acquisition  processes.  One  can  see  from  Figure  1  that  all  of  these 
systems  must  be  integrated  effectively  in  order  to  produce  a  successful  acquisition.  The 
Planning,  Programming,  Budget,  and  Execution  (PPBE)  system  is  responsible  for 
planning  and  tracking  programs  from  a  cost  perspective.  The  acquisition  process  as 
described  in  Department  of  Defense  Instruction  5000.02,  deals  with  the  design  and  build 
of  a  materiel  solution  for  a  particular  capability  gap,  and  the  JCIDS  process  identifies  and 
prioritizes  the  capability  gaps  based  on  the  national  defense  strategy. 


Acquisition 

Process 

DoDI  5000.2 


JCIDS 

Process 

Requirements 

Development 


PPBE 

Process 

Funding 


Figure  1.  DOD  Procurement  Systems  (from  DOD  2015) 
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Some  of  the  motivations  for  the  shift  from  a  requirements-based  process  to  a 
capability-based  acquisition  approach  can  be  gleaned  from  former  Secretary  of  State 
Rumsfeld.  In  a  speech  in  2001,  Rumsfeld  stated  that  the  legacy  of  acquisition  processes  is 
“really  a  relic  of  the  Cold  War — a  holdover  from  the  days  when  it  was  possible  to 
forecast  threats  for  the  next  several  decades”  (Garamone  2001,  1).  In  the  same  speech, 
Rumsfeld  noted  the  need  to  eliminate  redundant  processes  and  capabilities  that  occur 
when  a  new  system  is  created  every  time  a  new  threat  emerges.  Capability-based 
acquisition  also  mitigates  the  tendency  to  look  to  a  new  system  for  a  solution  as  opposed 
to  looking  at  existing  systems  for  solutions.  This  new  capability  approach  placed  a  new 
emphasis  on  developing  SoS.  System-of-systems  combine  individual  systems  to  achieve 
greater  capabilities  than  the  individual  systems  could  achieve  by  themselves  (Office  of 
the  Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology,  Systems  and 
Software  Engineering  [OSD]  2008). 

The  SoS  concept  came  to  the  forefront  in  a  vision  established  in  the  late  1990s, 
described  by  Charles  Dickerson  (2014)  in  his  chapter  of  Systems  of  Systems  Engineering: 
Principles  and  Applications  as  a  “revolution  in  military  affairs.”  This  revolution  of 
military  affairs  transitioned  from  the  conventional  force-on-force  that  characterized  the 
Cold  War  era  to  a  networked  arms  warfare  that  required  agility  and  flexibility.  According 
to  Dickerson,  the  rise  of  the  Internet  during  this  time  led  to  senior  leaders  envisioning  a 
battlespace  in  which  hardware  and  software  systems  could  be  integrated  across  multiple 
platforms.  The  benefits  of  this  approach  would  be  increased  situational  awareness,  faster 
communications,  and  quicker  and  more  precise  execution.  Additionally,  network-based 
acquisition  approach  would  facilitate  joint  operations,  which  have  become  commonplace 
in  military  operations.  In  the  Army,  specifically,  leaders  envisioned  commanders  being 
able  to  track  their  assets  on  the  battlefield  through  software  (Dickerson  2014).  By  the 
early  21st  century,  the  Army  shifted  from  platfonn-based  to  network-based  operations 
(Dickerson  2014).  The  structure  for  using  SoS  to  achieve  this  network-centric  concept 
can  be  seen  in  Figure  2. 
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Figure  2.  Comparison  of  Platfonn  Centric  Systems  Architecture  with 
Network-Centric  Systems  Architecture  (from  Dickerson  2014) 


On  the  left  side  of  the  diagram  in  Figure  2,  there  are  three  weapon  platfonns,  each 
with  its  own  battlespace.  In  this  case,  the  network  connectivity  of  each  platfonn  does  not 
extend  outside  of  the  particular  weapons  battlespace,  and  there  is  no  connectivity 
between  weapon  platforms.  On  the  right  side,  the  diagram  describes  a  networked  systems 
architecture  in  which  all  weapon  platforms  are  connected  and  integrated  into  a  single 
battlespace.  This  illustrates  the  potential  of  a  networked  system  of  systems.  When  the 
Army  moved  toward  a  network-centric  approach,  the  increased  connectivity  also  added 
complexity  to  systems  and  SoS.  With  this  rise  in  system  complexity,  there  was  a  renewed 
emphasis  on  the  systems  engineering  process,  which  facilitated  the  creation  of  many 
individual  systems.  By  2009,  there  were  ninety-six  individual  DOD  MDAPs  that  were  in 
various  phases  of  the  acquisition  process  (Fox  2012).  The  current  systems  engineering 
process  for  individual  systems  can  be  seen  in  Figure  3. 
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Figure  3.  Individual  Systems  Engineering  Process  for  Acquisitions  (from 

Manning  2014) 


As  seen  in  Figure  3,  the  systems  engineering  process  starts  with  an  operational 
need  and  ends  with  a  delivered  capability.  The  technical  processes  going  up  and  down  the 
V  are  described  in  the  adjacent  boxes,  and  the  technical  management  processes  are  used 
throughout  the  systems  engineering  process. 

Over  the  past  five  years,  the  DOD  has  made  an  effort  to  incorporate  system  of 
systems  engineering  into  the  acquisition  process.  Evidence  of  this  can  be  seen  with  the 
DOD  SoS  Guidebook  published  in  2008  (OSD  2008)  and  the  Navy’s  draft  SoS 
Engineering  Guidebook  released  in  2011  (Office  of  Assistant  Secretary  of  the  Navy 
(Research,  Development,  Acquisition)  [OASN  (RDA)]  2006).  The  intent  of  incorporating 
SoS  engineering  would  be  to  explore  the  idea  of  integrating  existing  systems,  as  opposed 
to  creating  new  systems  to  fill  capability  gaps.  Currently,  the  Anny  does  not  have  a 
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service-specific  guide  for  SoS  engineering.  This  thesis  explores  taking  a  deliberate  effort 
to  integrate  existing  and  future  Army  programs  into  a  system  of  systems.  This  would 
align  with  the  Army’s  plan  according  to  the  Anny  Acquisition  Policy,  AR  70-1,  which  is 
to  approach  all  materiel  acquisitions  from  an  SoS  perspective  (Department  of  the  Anny 
2011).  It  further  discusses  organizational  changes  that  would  have  to  take  place  in  order 
to  facilitate  such  an  effort. 

A.  OBJECTIVE 

The  objective  of  this  research  is  to  examine  the  acquisition  process  from  an  SoS 
perspective  and  identify  lessons  learned  and  best  practices  from  past  Army  attempts  to 
implement  SoS.  Additionally,  this  research  looks  at  current  SoS  engineering  processes 
and  organizational  changes  that  must  take  place  in  order  for  the  Army  to  successfully 
integrate  its  existing  programs  into  an  SoS.  The  goal  of  this  thesis  is  to  provide  a  starting 
point  for  a  possible  cultural  shift  away  from  the  individual  system  approach  to  an  SoS 
approach  for  addressing  capability  gaps. 

B.  PROBLEM  STATEMENT 

The  problem  that  the  Army  is  currently  experiencing  is  that  although  several 
Anny  systems  are  integrated  at  some  level,  the  Army  acquisition  policies  and  procedures 
are  structured  based  on  addressing  capability  gaps  using  an  individual  system  approach. 
This  is  evidenced  by  the  focus  on  individual  systems  in  Army  acquisition  regulations 
(such  as  the  AR  70-1)  and  guidelines  (such  as  the  Department  of  the  Army  Pamphlet  70- 
3  [DA  PAM  70-3]).  These  individual  systems  are  becoming  more  complex,  requiring 
more  resources,  and  several  have  been  cancelled  due  to  cost  or  schedule  overruns. 
Although  the  systems  engineering  process  is  commonplace  for  individual  system 
acquisition,  systems  engineering  for  SoS  rarely  takes  place,  if  it  takes  place  at  all.  This  is 
evidenced  by  the  fact  that  the  systems  engineering  for  SoS  is  not  explicitly  addressed  in 
Anny  acquisition  regulations.  This  thesis  addresses  the  need  for  the  Army’s  next  major 
program  to  make  a  deliberate  effort  to  implement  the  systems  engineering  process  for 
SoS,  and  the  organizational  changes  that  must  take  place  in  order  for  the  Anny  to 
effectively  implement  systems  engineering  for  SoS. 
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C.  RESEARCH  QUESTIONS 

This  thesis  attempts  to  answer  the  following  questions  in  order  to  recommend 
process  and  organizational  changes  to  the  current  acquisition  system  that  facilitate  an  SoS 
approach  to  current  and  future  Army  programs: 

1 .  What  are  some  of  the  lessons  learned  and  best  practices  that  can  be 
gleaned  from  the  Anny’s  past  attempts  at  SoS  acquisitions? 

2.  What  current  processes  in  the  Anny  acquisition  system  should  change,  be 
created,  or  be  implemented  as  policy  in  order  to  facilitate  systems 
engineering  from  an  SoS  perspective? 

3.  What  organizational  changes  in  the  Anny  need  to  take  place  to  facilitate  a 
successful  SoS  engineering  process? 

D.  SCOPE 

This  thesis  is  intended  to  apply  to  all  current  and  future  Anny  acquisition 
programs;  however,  this  thesis  will  focus  on  three  previous  SoS  acquisitions  as  case 
studies  to  recommend  process  and  organizational  changes  to  the  acquisition  system.  Due 
to  the  extensive  number  of  Army  programs,  the  research  does  not  detail  how  particular 
Anny  programs  could  be  integrated  into  an  SoS  architecture,  but  it  does  focus  on  lessons 
learned  and  best  practices  to  set  the  conditions  for  all  cunent  and  future  programs  to  be 
integrated  into  an  SoS  architecture.  Additionally,  this  thesis  examines  the  organizations 
involved  in  the  primary  steps  of  the  acquisition  process  and  recommends  changes  to 
facilitate  the  systems  engineering  process  from  an  SoS  perspective. 

E.  METHODOLOGY 

This  thesis  discusses  some  of  the  policy  and  doctrinal  changes  that  led  to  the 
acquisition  of  SoSs.  It  then  defines  different  SoS  types  and  details  the  core  elements  of 
SoS  engineering.  This  thesis  also  details  the  steps  of  the  acquisition  process  and  the 
personnel  and  processes  involved.  The  research  uses  the  seven  core  elements  of  SoS  as 
described  in  the  DOD  SE  guide  for  SoS  (OSD  2008)  as  a  framework  to  analyze  past 
Anny  SoS  programs  and  detennine  what  was  done  successfully  as  well  as  areas  for 
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improvement.  The  report  concludes  with  procedural  and  organizational  recommendations 
for  implementing  an  SoS  engineering  approach  to  current  and  future  Army  acquisitions. 


F.  THESIS  ORGANIZATION 

Chapter  II  of  this  thesis  is  a  literature  review,  which  focuses  on  the  Anny  SoS  and 
its  role  in  the  acquisition  process;  it  concludes  with  a  discussion  of  the  core  elements  of 
SoS  engineering.  Chapter  III  analyzes  three  past  Army  SoS  programs  using  core  elements 
of  SoS  engineering  as  described  in  the  DOD  SE  guide.  The  chapter  concludes  with 
lessons  learned,  which  are  used  to  recommend  process  and  organizational  changes  in  the 
following  chapters.  Chapter  IV  looks  at  the  major  processes  of  the  acquisition  process, 
and  discusses  process  changes  or  additions  needed  in  order  to  facilitate  the  systems 
engineering  process  for  SoS.  Chapter  V  examines  the  organizations  involved  in  the 
acquisition  process  and  recommends  changes  to  facilitate  the  system  engineering  process 
for  SoS.  Chapter  VI  concludes  with  a  summary  of  recommendations  and  areas  for  future 
research. 
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II.  LITERATURE  REVIEW 


In  order  to  go  forward  with  the  analysis  of  SoS  and  realize  how  it  relates  to  the 
Anny  acquisition  process,  it  is  important  to  understand  certain  definitions  and  processes 
that  are  relevant  to  SoS  during  the  acquisition  process.  The  DOD  defines  a  system  as  a 
“functionally,  physically,  and/or  behaviorally  related  group  of  regularly  interacting  or 
interdependent  elements;  that  group  of  elements  forming  a  unified  whole”  (OSD  2008, 

3) .  An  SoS  is  “a  set  or  arrangement  of  systems  that  results  when  independent  and  useful 
systems  are  integrated  into  a  larger  system  that  delivers  unique  capabilities”  (OSD  2008, 

4) .  According  to  the  SoS  SE  guide’s  definitions  of  a  system  and  an  SoS,  the  distinction 
between  the  two  is  that  once  a  system  is  established  and  is  broken  down  into  its 
components,  the  components  cannot  be  the  same  (OSD  2008).  An  example  of  this  can  be 
seen  with  a  car.  Once  the  engine  and  doors  and  wheels  are  separated  from  the  car,  the 
components  cannot  perfonn  the  same  functions  that  they  could  as  part  of  the  total  car 
system.  On  the  other  hand,  with  an  SoS,  individual  systems  can  theoretically  break  away 
from  the  SoS  and  provide  useful  capabilities.  An  example  of  this  is  two  systems 
connected  by  a  network,  such  as  iCloud.  Both  a  smart  phone  and  computer  can  share 
data  through  an  iCloud  but  each  system  can  also  function  independently.  The  flexibility 
inherent  in  an  SoS  is  an  important  concept  because  it  allows  some  flexibility  with 
individual  systems.  The  constituent  systems  of  an  SoS  can  be  attached  and  detached  from 
without  losing  their  individual  system  identity. 

An  SoS  is  different  from  a  family  of  systems.  A  family  of  systems  is  “a  set  of 
systems  that  provide  similar  capabilities  through  different  approaches  to  achieve  similar 
or  complementary  effects”  (OSD  2008,  4).  The  distinction  here  lies  in  the  capability.  For 
example,  the  Stryker  and  the  high-mobility  multipurpose  wheeled  vehicle  (HMMWV) 
would  be  considered  a  family  of  systems  because  they  both  provide  similar  capabilities. 
Both  are  used  as  methods  of  transportation  for  soldiers,  and  both  vehicles  have  the 
capability  to  mount  weapon  systems  for  security.  The  Stryker  has  a  greater  personnel 
capacity  and  the  armament  is  better  than  the  HMMWV,  but  the  combination  of  both  of 
these  vehicles  does  not  provide  any  unique  capabilities.  On  the  other  hand,  the  Ballistic 
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Missile  Defense  System  is  a  true  SoS  because  the  Air  Force’s  Upgraded  Early  Warning 
Radar  (UEWR)  combined  with  a  Patriot  System  provides  unique  capabilities  unavailable 
from  the  constituent  systems.  The  UEWR  can  detect  missiles  early  in  the  incoming 
missiles  flight  and  can  cue  the  incoming  missile  with  the  Patriot  System  so  that  the 
Patriot  can  engage  the  missile  at  the  optimal  time.  The  UEWR  alone  cannot  intercept  any 
missiles,  but  it  has  a  great  range  for  missile  detection.  The  Patriot  System  radar  can  detect 
missiles,  but  it  does  not  have  the  sensor  range  of  the  UEWR.  These  two  systems 
combined  as  well  as  several  other  systems  in  the  ballistic  missile  defense  SoS  come 
together  to  provide  greater  capabilities  against  missile  threats. 

An  SoS,  such  as  the  Ballistic  Missile  Defense  System  (BMDS),  comes  into 
existence  under  different  circumstances.  These  circumstances  can  be  categorized  into  one 
of  four  types  of  SoS,  as  illustrated  in  Table  1. 
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Table  1.  Categories  of  SoS  (from  MITRE  2014) 


Type 

Definition 

Virtual 

Virtual  SoSs  lack  a  central  management  authority  and  a  centrally 
agreed-upon-purpose  for  the  system-of-systems.  Large-scale 
behavior  emerges — and  may  be  desirable — but  this  type  of  SoS  must 
rely  on  relatively  invisible  mechanisms  to  maintain  it. 

Collaborative 

In  collaborative  SoSs,  the  component  systems  interact  more  or  less 
voluntarily  to  fulfill  agreed  upon  central  purposes.  The  Internet  is  a 
collaborative  system.  The  Internet  Engineering  Task  Force  works 
out  standards  but  has  no  power  to  enforce  them.  The  central  players 
collectively  decide  how  to  provide  or  deny  service,  thereby 
providing  some  means  of  enforcing  and  maintaining  standards. 

Acknowledged 

Acknowledged  SoSs  have  recognized  objectives,  a  designated 
manager,  and  resources.  However,  the  constituent  systems  retain 
their  independent  ownership,  objectives,  funding,  development,  and 
sustainment  approaches.  Changes  in  the  systems  are  based  on 
collaboration  between  the  SoS  and  the  system. 

Directed 

Directed  SoSs  are  those  in  which  the  integrated  system-of-systems  is 
built  and  managed  to  fulfill  specific  purposes.  It  is  centrally 
managed  during  long-term  operation  to  continue  to  fulfill  those 
purposes  as  well  as  any  new  ones  the  system  owners  might  wish  to 
address.  The  component  systems  maintain  an  ability  to  operate 
independently,  but  their  normal  operational  mode  is  subordinated  to 
the  central  managed  purpose. 

An  example  of  a  virtual  SoS  is  the  DOW  Jones  Industrial.  Shareholders  and  CEOs 
have  some  level  of  control  over  the  individual  companies  or  systems  that  make  up  the 
DOW,  but  there  is  no  central  authority  that  manages  the  DOW  as  a  whole.  Financial 
capital,  which  often  is  fueled  by  consumer  confidence,  is  the  mechanism  that  maintains 
the  DOW.  It  is  relatively  invisible  because  individual  investors  will  buy  and  sell  the  stock 
based  on  their  personal  beliefs  about  a  particular  company.  One  can  only  speculate  the 
reasons  why  the  DOW  may  go  up  or  down. 
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One  property  that  is  especially  prevalent  in  a  virtual  SoS  is  emergence. 
Emergence,  as  stated  by  Charles  Keating,  occurs  when  “pattems/properties  in  a  complex 
system  will  come  about  (emerge)  through  operation  of  the  system.  These 
pattems/properties  cannot  be  anticipated  beforehand  and  are  not  capable  of  being 
deduced  from  understanding  of  system  constituents  or  their  individual  properties” 
(Keating  2014,  170).  Emergence  occurs  in  systems  and  SoS.  In  a  virtual  SoS,  there  is 
little  to  no  planning  for  emergence,  so  with  the  example  of  the  DOW,  there  are  numerous 
trades  taking  place  during  the  day  by  millions  of  people.  This  could  cause  the  DOW  to 
rise  significantly.  This  may  lead  to  emergent  behavior  such  as  investors  believing  that  the 
DOW  is  overvalued  and  consequently  beginning  to  sell,  or  it  could  cause  companies  to 
make  a  business  decision  based  on  the  DOWs  perceived  value  that  reverses  the  upward 
trend.  These  emergent  behaviors  can  produce  both  positive  and  negative  consequences. 

The  Internet,  as  stated  in  Table  1,  is  a  collaborative  SoS.  Information  comes  from 
many  different  sources,  but  can  be  monitored,  and,  if  necessary,  censored  by  federal 
authorities.  Several  nations  around  the  world  censor  infonnation  available  on  the  Internet, 
usually  through  their  government.  In  this  regard  the  Internet  is  a  collaborative  SoS 
because  each  nation  has  its  own  way  of  monitoring  and  regulating  the  infonnation  that  is 
seen  on  websites.  Additionally,  various  websites  come  together  to  provide  diverse 
information  on  a  myriad  of  topics.  Different  nations  have  different  standards,  and 
although  each  nation  is  able  to  centrally  manage  infonnation  in  their  respective  nations, 
there  is  no  global  authority  that  controls  what  is  posted  on  the  Internet.  In  this  sense,  the 
Internet  is  virtual,  with  no  central  authority  and  no  central  agreement  on  the  purpose  of 
the  Internet. 

Acknowledged  and  Directed  SoSs  are  more  commonplace  in  the  DOD.  An 
example  of  an  acknowledged  SoS  is  the  BMDS.  All  systems  in  the  ballistic  missile 
defense  system  come  together  to  combat  a  common  threat  of  intercepting  ballistic  and 
cruise  missiles  launched  by  land,  sea,  or  air.  Each  system  within  the  BMDS  is  managed 
separately  and  has  its  own  line  of  funding.  For  example,  the  Terminal  High  Altitude 
Defense  (THAAD)  system  is  managed  by  the  Army  while  the  Aegis  system  is  managed 
by  the  Navy.  The  BMDS  SoS  is  managed  by  the  missile  defense  agency  (MDA).  The 
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MDA  is  primarily  responsible  for  integrating  these  individual  systems.  According  to  the 
DOD  systems  engineering  guide,  “most  military  systems  are  part  of  an  SOS  even  if  they 
are  not  explicitly  recognized  as  such”  (OSD  2008,  4).  This  suggests  that  most  DOD  SoSs 
are  acknowledged  as  opposed  to  directed.  Although  the  ballistic  missile  defense  system  is 
an  acknowledged  SoS,  the  missile  defense  agency  does  not  explicitly  state  that  BMDS  is 
an  SoS.  It  refers  to  BMDS  as  “the  system”  on  its  webpage,  and  the  individual  systems  as 
“elements”  (Missile  Defense  Agency  2014).  The  tenn  elements  suggest  that  each  part  of 
the  BMDS  is  not  a  system  in  itself.  This  is  characteristic  of  several  Army  programs. 
These  programs  are  acknowledged  as  an  SoS,  though  a  lot  of  the  tenninology  and 
processes  resemble  a  system. 

The  last  category  of  SoS  is  the  directed  SoS.  The  most  recent  example  of  an 
Army-directed  SoS  is  the  Army  Future  Combat  Systems  (FCS).  This  is  the  most 
significant  attempt  at  an  Army  SoS.  This  was  a  first  for  the  Army,  and  the  Army  has  not 
attempted  to  design  and  build  a  directed  SoS  since  the  FCS.  The  FCS  was  initiated  in 
2003  with  the  intention  of  transforming  the  Anny  into  a  lighter,  more  agile  force.  This 
program  was  intended  to  function  as  an  SoS,  and  was  centrally  managed  by  high-ranking 
Anny  and  civilian  personnel.  According  to  a  RAND  study,  this  was  the  “most  ambitious 
acquisition  program  in  Anny  history”  (Pemin  et  al  2012,  iii).  The  program  was  cancelled 
in  2009  for  a  variety  of  reasons.  An  in-depth  analysis  of  the  decisions  and  processes 
followed  during  the  acquisition  of  the  FCS  occurs  in  subsequent  chapters. 

A.  SYSTEMS  ENGINEERING  IN  SOS 

Most  of  the  processes  that  occur  throughout  any  system’s  lifecycle  are  influenced 
by  the  systems  engineering  process.  The  systems  engineering  process  grew  out  of  a  need 
to  analyze  programs  holistically.  It  can  be  traced  back  to  the  1960s,  when  Secretary 
McNamara  and  his  staff  through  the  DOD  Reorganization  Act  of  1958  created  the  Office 
of  Systems  Analysis  (Fox  2012).  This  was  in  response  to  several  cost  and  schedule 
overruns  that  occurred  in  programs  such  as  the  C-5A,  the  F-  111,  and  the  SRAM -A  (Fox 
2012).  The  Systems  engineering  process  continued  to  develop  in  later  decades,  and 
became  a  discipline  in  several  universities  by  the  late  1990s.  Currently,  the  systems 
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engineering  process  is  mandated  in  the  Anny  Acquisition  Policy,  AR  70-1.  The  policy 
states,  “Regardless  of  the  acquisition  category,  all  programs  shall  develop  and  follow  a 
systems  engineering  plan  to  execute  and  manage  a  disciplined  systems  engineering 
process  supporting  the  acquisition  strategy  adopted  by  the  program”  (Department  of  the 
Army  2011,  41).  Therefore,  it  is  logical  that  systems  engineering  processes  would  play  a 
significant  role  in  SoS  as  well.  Although  the  Army  specifically  mandates  that  a  systems 
engineering  process  must  be  implemented  throughout  the  entire  life  cycle  of  the  system, 
there  is  no  mention  of  an  SoS  engineering  process  to  guide  the  SoS  acquisition  process. 
Systems  engineering  for  a  system  and  an  SoS  is  very  different.  The  chart  in  Table  2 
compares  the  systems  engineering  and  SoS  engineering  considerations. 


14 


Table  2.  Comparison  of  SE  for  a  System  and  SoS  (from  Dahmann  2014) 


System 

System  of  Systems 

Management  /Oversight 

Stakeholder  Involvement 

Clear  set  of  stakeholders 

Added  levels  of  complexity; 
stakeholders  at  both  system  level 
and  levels  with  competing  interests 
and  priorities;  in  some  cases 
the  system  stakeholder  has  no 
vested  interest  in  the  SoS 

Governance 

Single  PM  and  funding 

May  have  management  and 
funding  for  the  SoS  but  also  have 
management  and  funding  of 
for  individual  systems 

Operational  Environment 

Operational  Focus 

The  systems  are  designed  and 
developed  to  meet  operational 
objectives 

SoS  is  called  upon  to  meet  a 
set  of  operational  objectives 
using  systems  whose  objectives 
may  or  may  not  align  with  the 

SoS  objectives 

Implementation 

Acquisition/Test  & 

Validate 

Established  process  aligned  to 
ACAT  milestones,  specified 
requirements,  SE  with  a 
systems  engineering  plan 
(SEP) 

No  established  process  across 
multiple  system  lifecycles 
across  acquisition  programs, 
involving  legacy  systems, 
developmental  systems,  and 
technology  insertion 

Testing  or  validating  the  system 
is  possible 

Testing  is  more  challenging 
due  to  the  difficulty  of 
synchronizing  across  multiple 
systems  life  cycles;  testing  all 
permutations,  given  the 
complexity  of  all  the  moving 
parts,  is  not  possible 

Engineering 

Boundaries  and  Interlaces 

Focuses  on  boundaries  and 
interfaces  for  the  single 
system 

In  SoS  the  focus  is  on 
identifying  the  systems  that 
contribute  to  the  SoS 
objectives  and  enabling  the 
llow  of  data,  control  and 
functionality  of  the  SoS  within  the 
constraints  of  the  systems 

Performance  &  Behavior 

Optimize  performance  of  the 
system  to  meet  performance 
objectives 

Provide  end-to-end 
performance  across  the  SoS 
that  satisfies  user  capability 
needs  within  the  context  and 
constraints  of  the  systems 
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Based  on  the  table,  some  of  the  key  differences  in  the  systems  engineering 
processes  deal  with  management.  The  systems  engineering  process  frequently  deals  with 
gathering  information  from  stakeholders  and  addressing  their  perspectives  in  the  system. 
While  a  system  may  have  stakeholders  with  multiple  perspectives,  stakeholders  are  all 
focused  on  the  system,  whereas  in  the  SoS  environment,  stakeholders  may  or  may  not  be 
vested  in  the  SoS,  and  each  stakeholder  perspective  may  represent  a  different  system. 
Another  aspect  of  systems  engineering  is  the  relationship  between  the  systems  engineer 
and  the  program  manager.  Systems  generally  are  assigned  one  program  manager  (PM), 
and  in  an  SoS  there  usually  is  an  SoS  manager  that  must  coordinate  with  several  PMs. 
The  relationship  between  the  systems  engineer  and  the  SoS  manager  is  different  from  the 
relationship  between  a  systems  engineer  and  project  manager  because  the  SoS  manager 
has  limited  influence  on  the  individual  systems,  whereas  the  program  manager  usually 
has  influence  over  the  system  subcomponents. 

Systems  engineering  is  also  focused  on  testing.  The  chart  in  Table  2  describes 
how  testing  is  more  difficult  for  an  SoS  because  different  systems  may  be  in  different 
development  stages,  which  usually  precludes  testing  the  entire  SoS.  Consequently,  testing 
rarely  occurs  at  the  SoS  level.  The  constituent  systems  that  make  up  the  SoS  usually  are 
tested  without  the  benefit  of  integration  testing.  The  lack  of  integration  testing  places  the 
SoS  at  risk  of  operational  failure  when  the  SoS  is  fielded  for  operational  use. 
Furthennore,  the  systems  engineering  process  focuses  on  establishing  boundaries  so  that 
the  system  has  the  proper  scope.  This  is  challenging  when  dealing  with  SoS  because 
systems  are  coming  in  with  established  boundaries,  and  changing  these  boundaries  to 
accommodate  an  SoS  may  not  align  with  the  stakeholders’  intended  use  for  the  individual 
system.  Based  on  the  differences  between  systems  engineering  and  SoS  engineering,  it  is 
important  for  the  Anny  to  emphasize  these  differences  in  Army  acquisition  policy.  The 
systems  engineering  guide  for  the  DOD  discusses  core  elements  of  SoS  engineering. 
Figure  4  shows  the  core  elements  and  the  relationships  between  them. 
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External  Environment 


Figure  4.  SoS  Core  Elements  and  Their  Relationships  (from  OSD  2008) 


B.  CORE  ELEMENTS  OF  SOS  ENGINEERING 

These  seven  core  elements  are  described  in  detail  in  the  SoS  System  Engineering 
(SE)  Guidebook  (OSD  2008),  and  will  serve  as  the  analytical  framework  for  Army  SoS 
programs  in  later  chapters.  The  seven  elements  are  discussed  briefly  in  the  following 
section. 

(1)  Translating  Capability  Objectives 

An  important  part  of  the  acquisition  process  is  taking  the  capability  objectives 
established  during  the  JCIDS  process  and  translating  them  to  a  materiel  solution,  if 
required.  Capability  objectives  for  an  SoS  are  often  very  broad  in  nature  (OSD  2008),  and 
must  be  refined  during  the  SoS  SE  acquisition  process  in  order  to  accurately  portray  the 
way  each  constituent  system  will  work  together  to  achieve  the  desired  capabilities.  An 
example  of  a  broad  capability  is  to  facilitate  data  transfer  between  multiple  platforms. 
This  capability  must  be  refined  to  describe  the  interoperable  capability  that  each  platform 
must  have,  and  the  type  of  data  each  system  must  be  capable  of  transferring. 
Furthermore,  the  SoS  manager  must  be  able  to  articulate  what  part  each  system  will  play 

in  providing  the  overall  capability  required.  This  is  often  easier  to  glean  from  a  functional 
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decomposition  of  a  single  system.  In  an  SoS,  there  will  be  a  functional  decomposition  of 
all  the  constituent  systems,  and  possibly  an  additional  functional  decomposition  that 
traces  the  functions  of  the  constituent  systems  with  the  overall  capability  objectives. 
Although  the  SoS  SE  guide  states  that  SoS  engineers  operate  under  the  assumption  that 
all  constituent  systems  go  through  the  systems  engineering  process,  the  SoS  Systems 
engineer  will  at  a  minimum  have  to  understand  the  way  each  system’s  functions 
contribute  to  the  overall  objective.  This  understanding  is  necessary  to  facilitate  a 
capability  to  requirements  crosswalk  that  is  essential  in  systems  engineering. 

(2)  Understanding  System  Relationships 

If  the  SoS  manager  or  engineer  does  not  understand  the  relationships  between  the 
subordinate  systems,  the  SoS  will  be  at  risk  of  not  meeting  capability  requirements,  or 
risk  significant  cost  and  schedule  overruns.  In  essence,  the  SoS  will  likely  fail  in  the  long 
run  if  relationships  between  systems  are  not  understood.  Understanding  system 
relationships  goes  beyond  how  the  physical  components  are  related  and  how  they 
interface.  Understanding  system  relationships  means  understanding  the  boundaries  and 
constraints  of  each  system  (OSD  2008).  These  could  be  cost  and  schedule  constraints  or 
constraints  imposed  by  political  figures.  The  challenges  associated  with  administrative 
relationships  could  be  more  difficult  to  overcome  than  the  challenges  stemming  from 
physical  component  relationships.  This  does  not  mean  that  the  physical  component 
relationships  should  be  ignored.  Software  and  networking  are  a  growing  part  of  the 
acquisition  process.  An  SoS  engineer  must  understand  the  interface  requirements  for  each 
subordinate  system  in  order  to  assess  technological  and  financial  risks  associated  with 
SoS  integration.  The  SoS  engineer  must  also  be  mindful  of  how  these  relationships  will 
change  over  time  when  one  individual  system  retires  or  upgrades. 

(3)  Assessing  Performance  to  Capability  Objectives 

In  systems  engineering,  capabilities  are  usually  mapped  to  functions,  and 
functions  are  assessed  based  on  measures  of  performance  and  measures  of  effectiveness. 
Measures  of  perfonnance  for  an  SoS  may  conflict  with  measures  of  perfonnance  of  a 
constituent  system.  An  individual  system  may  have  to  perform  sub-optimally  in  order  for 


18 


the  SoS  to  perform  optimally  (OSD  2008).  For  example,  a  sensor  on  a  particular  weapon 
system  may  function  optimally  when  its  sensor  is  actively  searching;  however,  when  the 
weapon  system  operates  in  an  SoS,  the  weapon  system  may  cause  interference  for 
another  sensor  with  greater  detection  range.  This  may  require  that  the  first  system  turn  off 
its  sensor  and  depend  on  the  second  system  to  do  target  searching.  In  this  case,  the  first 
system  is  not  in  its  optimal  state,  but  it  still  has  a  weapon  system  that  will  make  the  SoS 
function  optimally  with  assistance  from  the  second  system’s  sensor. 

The  assessment  of  a  function’s  ability  to  meet  its  objectives  is  usually  solidified 
through  operational  testing  of  the  system  (OSD  2008).  This  becomes  more  challenging 
when  dealing  with  SoS.  In  order  to  conduct  an  operational  test  on  an  SoS,  all  of  the 
individual  systems  must  be  at  a  point  where  they  can  be  operationally  tested.  This  means 
that  coordination  between  the  SoS  manager  and  the  subordinate  systems  is  essential  in 
order  to  facilitate  operational  testing.  Oftentimes,  operational  testing  before  fielding  is 
not  feasible  based  on  the  constraints  of  the  subordinate  systems.  As  a  result,  most  SoS 
testing  is  done  through  simulation  (OSD  2008).  There  are  always  limitations  when 
dealing  with  simulations  because  certain  assumptions  must  be  made.  Further,  these 
assumptions  in  simulation  can  result  in  a  limited  ability  to  capture  the  emergence  that 
occurs  when  actual  systems  interface  with  each  other.  It  is  therefore  important  to 
understand  and  articulate  the  risk  associated  with  the  data  that  comes  from  simulation 
testing  on  an  SoS.  If  possible,  the  actual  systems  should  be  used  to  conduct  operational 
testing.  This  will  yield  the  most  accurate  results,  and  possibly  be  a  good  investment  that 
mitigates  the  cost  incurred  from  employing  a  system  based  on  inaccurate  data. 

(4)  Developing  and  Evolving  SoS  Architecture 

The  Department  of  Defense  architecture  views  (DODAF)  provide  guidelines  on 

ways  to  display  the  architecture  for  systems  and  SoS.  The  SoS  SE  guide  states  that 

requirements  often  evolve  from  architectural  views  and  architectural  views  evolve  from 

requirements.  Important  architectural  views  for  an  SoS  must  address  the  relationships 

between  constituent  systems  (OSD  2008).  This  can  be  done  with  a  high-level  operational 

concept  graphic  (OV-1)  that  details  the  concept  of  operations  for  the  SoS.  Viewing  the 

system  from  an  operational  perspective  allows  stakeholders  to  see  how  the  system 
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achieves  its  required  capabilities.  There  are  several  other  SoS  architectural  views  in 
DODAF  that  can  be  utilized  based  on  the  requirements  of  the  specific  SoS.  In  addition  to 
developing  the  baseline  architecture,  SoS  architecture  must  evolve  to  accommodate  the 
dynamic  nature  of  an  SoS.  SoS  architecture  should  account  for  changes  in  individual 
systems.  For  example,  if  a  system  upgrades  its  software,  interface  views  should  be 
updated  to  reflect  the  software  upgrade’s  impact  on  the  SoS.  This  holds  true  for  a  system 
that  may  be  retired  as  well,  as  this  will  certainly  have  an  impact  on  the  SoS. 

(5)  Monitoring  and  Assessing  Changes 

It  is  important  to  keep  track  of  changes  in  the  constituent  systems  because  they 
may  have  an  effect  on  the  SoS.  For  example,  an  upgrade  on  the  software  of  a  particular 
system  could  affect  the  interoperability  between  that  system  and  other  systems.  Similarly, 
changes  in  physical  components  also  must  be  accounted  for,  as  they  may  affect  physical 
connections  between  other  systems.  It  is  important  that  these  changes  are  planned  in 
advance  so  that  the  effects  on  the  SoS  can  be  assessed.  In  addition  to  technical  changes  to 
the  systems,  there  are  changes  to  the  programs.  SoS  managers  must  be  cognizant  of  any 
changes  in  funding  for  constituent  systems.  For  example,  in  the  event  of  a  sequestration 
where  several  budgets  are  cut,  the  SoS  manager  must  understand  the  implications  of  the 
funding  changes  and  how  the  funding  limitations  impact  SoS  perfonnance. 

It  is  important  for  SoS  managers  to  document  configuration  changes  in  individual 
systems  in  case  changes  degrade  SoS  perfonnance  (OSD  2008).  The  SoS  may  need  to  go 
back  to  a  baseline  configuration  if  interoperability  issues  arise  from  physical  or  software 
upgrades  in  constituent  systems.  This  would  not  be  possible  without  a  robust 
configuration  management  plan  with  detailed  documentation.  SoS  may  have  to 
accommodate  changes  in  subordinate  systems,  so  this  may  wanant  a  bottom-up  analysis 
to  detennine  the  effect  of  a  constituent  system  change  on  the  SoS. 

(6)  Addressing  Requirements  and  Solution  Options 

In  systems  engineering,  the  analysis  of  alternatives  focuses  on  system  components 
and  how  they  will  best  achieve  the  required  capabilities  given  the  system  constraints 
(Blanchard  and  Fabrycky  2010).  This  becomes  more  challenging  when  dealing  with  an 
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SoS,  because  trade-offs  in  an  SoS  often  involve  concessions  from  individual  systems  that 
have  already  gone  through  an  analysis  of  alternatives  to  bring  their  systems  into  existence 
(OSD  2008).  The  trade-offs  in  the  systems  engineering  process  for  a  system  can  often  be 
balanced  with  cost  efficiency  and  its  ability  to  achieve  a  desired  measure  of  performance. 
SoS  trade-offs  could  potentially  be  more  complicated,  as  certain  trade-offs  may  be  made 
just  to  get  constituent  systems  to  buy  in  to  the  SoS.  Extensive  negotiations  must  take 
place  so  that  each  individual  system’s  stakeholder  feels  comfortable  with  its  role  in  the 
SoS  (OSD  2008).  In  a  directed  SoS,  this  could  take  years,  because  each  individual  system 
would  have  to  go  through  its  own  analysis  of  alternatives,  followed  by  an  analysis  of 
alternatives  for  the  SoS. 

(7)  Orchestrating  SoS  Upgrades 

The  difference  between  a  system  upgrade  and  an  SoS  upgrade  can  be  seen  by 
comparing  the  upgrade  in  software  that  occurred  on  the  Patriot  System  to  go  from  PAC-2 
to  PAC-3  missiles  as  opposed  to  a  software  upgrade  for  the  complete  BMDS.  Because 
SoS  upgrades  are  very  large  undertakings,  the  SoS  Engineering  Guide  advocates 
upgrading  in  increments  (OSD  2008).  Orchestrating  SoS  upgrades  must  take  all  of  the 
other  six  core  elements  into  consideration  in  order  to  be  executed  successfully.  A  system 
mapping  to  capability  requirements  should  be  carefully  planned,  resourced,  and  modeled 
to  ensure  that  the  SoS  upgrade  is  executed  in  the  most  efficient  manner  that  maximizes 
perfonnance. 

The  SoS  systems  engineering  process  is  depicted  in  Figure  5.  Notable  in  this 
diagram  is  that  the  SoS  process  assumes  that  each  individual  system  acquisition  is 
executed  using  the  systems  engineering  process  (OSD  2008). 
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Figure  5.  SoS  Engineering  Processes  (from  OSD  2008) 


The  following  chapters  discuss  past  and  present  Army  programs  through  the  lens 
of  these  core  elements  to  determine  the  best  practices  for  an  SoS  approach  to  all  existing 
and  future  Army  programs  as  well  as  if  implemented,  how  the  SoS  approach  should  be 
executed. 
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III.  ARMY  SYSTEM  OF  SYSTEMS 


This  chapter  will  examine  three  case  studies  of  previous  Army  SoS  acquisitions, 
the  Counter  Rocket  Artillery  Mortar  System  (C-RAM),  the  Anny  Battle  Command 
System  (ABCS),  and  the  Future  Combat  System  (FCS).  Using  the  core  elements  from 
SoS  engineering,  lessons  learned  will  be  obtained  in  order  to  make  recommendations  for 
process  and  organizational  changes  for  current  and  future  Army  SoS  acquisitions. 

A.  COUNTER  ROCKET  ARTILLERY  MORTAR  SYSTEM 

The  C-RAM  is  an  SoS  built-in  response  to  the  indirect  fire  that  was  impacting 
operations  in  Iraq  and  Afghanistan.  The  SoS  was  built  in  2004  based  on  an  Operational 
Need  Statement  from  Multinational  Forces  in  Iraq.  Leaders  expressed  a  need  for  early 
identification  and  destruction  of  incoming  mortars  in  order  to  reduce  the  adverse  effects 
of  operations  in  the  Area  of  Responsibility  (AOR)  (Whaley  and  Stewart  2014).  The  C- 
RAM  was  built  largely  from  existing  systems  from  different  Army  branches  as  well  as 
different  services.  The  Forward  Area  Air  Defense  Command  and  Control  (FAAD  C2)  is 
the  main  command  and  control  system  for  the  C-RAM.  It  uses  hardware  and  software  to 
provide  an  air  picture  for  the  operator  (Program  Executive  Officer  Missiles  &  Space — 
Anywhere — All  the  Time  [PEO]  2015).  It  is  used  by  divisional  or  short  range  air  defense 
units  to  support  the  Anny  air  defense  mission  by  providing  an  air  picture  to  complement 
other  Army  air  defense  systems,  such  as  Patriot  and  THAAD.  The  C-RAM  also  uses  the 
Air  and  Missile  Defense  Planning  and  Control  System  (AMDPCS)  that  provides  an  air 
picture  for  all  echelons  of  air  defense,  the  Air  and  Missile  Defense  Workstation 
(AMDWS)  that  initially  was  created  as  the  Command  and  Control  center  for  PATRIOT, 
Systems.  The  C-RAM  provides  an  air  picture  for  short  range  ballistic  weapons,  and  also 
can  simulate  engagements  on  the  battlefield  based  on  a  threat  profile  and  friendly 
capabilities  (PEO  2015).  The  C-RAM  SoS  also  has  early  warning  and  cueing  capabilities. 
These  cueing  capabilities  are  provided  by  a  wireless  system  called  Warn,  which  uses 
wireless  technology  to  integrate  with  existing  security  systems  and  provide  audio  and 
visual  warning  in  the  AOR.  The  radar  that  provides  the  air  picture  for  the  C-RAM  is  the 
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AN/TPQ  36  and  37  radars  (PEO  2015).  These  radars  initially  were  created  to  support  the 
field  artillery  mission  of  detecting  short-  and  long-range  rockets  and  mortars.  They 
currently  provide  detection  capability  for  the  C-RAM  (Higgins  2007).  The  weapon 
system  for  the  C-RAM  is  a  version  almost  identical  to  the  Navy  MK  15  Phalanx  close-in 
weapon  system  (CWIS)  used  as  the  final  layer  of  defense  for  ships.  Adjustments  had  to 
be  made  to  convert  the  ship-based  platfomi  into  a  land-based  platform  (PEO  2015).  The 
diagram  in  Figure  7  illustrates  the  SoS  architecture  for  the  C-RAM. 


Figure  6.  C-RAM  SoS  Architecture  (from  Bloodsworth  2010) 


( 1 )  Acquisition  Process 

One  of  the  notable  accomplishments  about  the  C-RAM  project  was  that  it  took 
less  than  fifteen  months  to  go  from  operational  need  to  an  initial  operating  system 
(Archer  2014).  The  unclassified  C-RAM  performance  ranges  from  a  60-70  percent 
probability  of  intercept  against  incoming  mortars  (Global  Security  2015).  In  addition, 
during  OIF,  the  C-RAM  provided  early  warning  for  over  1,500  incoming  rounds  (Army 
C-RAM  Intercepts  100th  Mortar  Bomb  in  Iraq  2009).  Archer  states  the  “C-RAM 
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leveraged  existing  technologies  within  the  DOD  and  private  sector  to  curtail  the  typical 
system-of-systems  acquisition  timeframe  of  10-20  years”  (2014,  32).  Using  the  core 
elements  of  SE  SoS,  the  thesis  examines  the  C-RAM  acquisition  process  in  the  next 
section. 

(2)  Translating  Capability  Objectives 

Translating  capability  objectives  must  start  with  a  broad  need  statement  especially 
for  SoS.  The  C-RAM  is  in  the  category  of  an  acknowledged  SoS.  The  Operational  Need 
Statement  called  for  “an  indirect-fire  intercept  capability”  (Corbett  2012,  47)  during 
Operation  Iraqi  freedom.  The  need  statement  meets  the  criteria  for  a  broad  SoS  capability 
need  because  it  is  general  enough  to  facilitate  an  analysis  of  alternatives  and  also 
effectively  describes  the  need  for  personnel  in  theater.  The  fact  that  the  threat  was 
immediate,  instead  of  the  forecasted  threats  that  usually  drive  the  acquisition  process, 
provided  context  for  the  designers  and  builders  to  create  a  system  to  meet  the  users’ 
needs. 

(3)  Understanding  Systems  and  Relationships 

The  C-RAM  consists  of  the  land-based  Phalanx  weapon  system  for  intercept 
purposes,  the  Forward  Area  Air  Defense  Command  and  Control  (FAAD  C2)  and  Air  and 
Missile  Defense  Workstation  (AMDWS)  for  command  and  control  functions.  The 
Lightweight  Counter  Mortar  and  Firefinder  radars  from  the  Field  Artillery  branch  were 
used  as  sensors,  and  the  Warn  system  used  for  early  warning.  One  of  the  strengths  of  the 
C-RAM  acquisition  process  was  the  ability  to  understand  systems  and  relationships.  One 
of  the  reasons  for  this  is  that  the  C-RAM  started  with  a  Joint  Urgent  Operational  Needs 
Statement  (JUONS).  The  JUONS  was  created  in  2004  to  facilitate  a  more  streamlined 
acquisition  process  to  counter  urgent  threats.  The  JUONS  ensured  that  multiple 
perspectives  examined  these  needs  (Whaley  and  Stewart  2014). 

Another  demonstration  of  the  decision  authority  demonstrating  an  understanding 
of  systems  and  relationships  in  the  C-RAM  was  their  ability  to  decompose  the  problem 
statement  effectively.  This  was  evident  in  the  way  C-RAM  acquisition  was  task 
organized.  For  example,  the  Field  Artillery  branch  of  the  U.S.  Army  was  the  first  branch 
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involved  with  the  C-RAM  because  the  Field  Artillery  already  had  systems  with  the 
ability  to  detect  short-  and  long-range  mortars.  Although  the  field  artillery  could  identify 
mortar  locations,  they  did  not  have  C2  systems  capable  of  simultaneously  providing 
intelligence,  and  maintain  a  common  operating  air  picture  in  a  joint  environment. 
(Higgins  2007).  This  is  where  the  Army  Air  Defense  came  into  play.  The  decision 
makers  demonstrated  understanding  that  the  FA  AD  C2  and  AMDWS  provided  the  C2 
needed  for  the  C-RAMs  operational  environment.  The  decision  maker  understood  that 
that  neither  the  Air  Defense  nor  Field  artillery  had  the  offensive  capability  to  intercept 
incoming  mortars.  This  led  to  the  inclusion  of  the  land-based  Phalanx  weapon  system  that 
was  used  in  the  Navy  at  sea.  The  Navy  demonstrated  the  capability  to  defend  against 
incoming  mortars  with  the  CWIS,  so  it  made  sense  to  utilize  the  Navy’s  experience  in 
developing  an  intercept  capability  for  the  C-RAM  (PEO  2015).  The  warning  capability 
was  given  to  contractors.  Clearly,  decision  makers  understood  the  relationships  between 
the  C-RAM  constituent  systems,  and  demonstrated  a  great  understanding  of  the  C-RAMs 
operational  requirements  to  effectively  decompose  the  problem  to  incorporate  existing 
systems  from  different  branches  of  the  Anny  and  Navy. 

(4)  Assessing  Performance  to  Capability  Objectives 

Assessing  the  perfonnance  to  capability  objectives  usually  happens  during 
operational  testing.  All  of  the  subordinate  systems  were  available  to  conduct  a  full 
operational  test  during  the  C-RAM  acquisition.  This  is  a  rare  occurrence  in  SoS  because, 
as  described  in  Chapter  II  of  this  study,  testing  all  constituent  systems  simultaneously  is 
challenging.  Testing  systems  individually  is  different  from  testing  the  SoS  because 
interoperability  testing  is  a  significant  undertaking  for  an  SoS.  Assessing  the  perfonnance 
to  capability  objectives  for  this  SoS  was  relatively  straightforward  in  part  because  the 
need  statement  was  clearly  defined.  Additionally,  similar  capability  objectives  are 
required  for  the  tracking,  detection,  and  interception  of  any  incoming  target,  and  the 
DOD  had  extensive  experience  meeting  these  objectives  from  prior  air  and  missile 
defense  systems.  Operational  testing  was  conducted  in  Yuma,  AZ,  by  an  Air  Defense 
unit.  The  C-RAM  SoS  represented  systems  from  different  branches  of  the  military,  but 
the  users  and  testers  were  all  in  the  Air  Defense  branch.  A  critical  part  of  operational 
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testing  is  for  users  with  contextual  knowledge  of  the  system  to  provide  feedback  on 
system  performance.  Given  that  the  concept  of  joint  operations  was  still  relatively  new  to 
the  DOD,  there  was  little  initial  effort  to  involve  other  branches  and  services  in  the 
operational  testing.  As  a  result,  an  assessment  of  perfonnance  to  capability  objectives 
was  successful  but  could  have  been  enhanced  if  more  effort  was  placed  on  incorporating 
users  from  different  branches  of  the  Army. 

(5)  Developing  and  Evolving  an  SoS  Architecture 

The  development  of  the  initial  SoS  architecture  was  facilitated  through  the  close 
relationship  with  acquisition  decision-makers  and  the  Army  testing  agency.  C-RAM  did 
not  introduce  any  new  capabilities  without  going  through  Army  Test  and  Evaluation 
Command  (ATEC).  Effective  communication  between  the  PMs  also  facilitated  an 
evolving  architecture  for  the  C-RAM.  Although  it  was  developed  in  a  short  period  of 
time,  the  changes  that  occurred  were  smooth  due  to  the  communication  between  PMs  and 
communication  with  the  testing  agency.  During  a  test  and  evaluation  (T&E)  briefing, 
Bloodsworth  (2009)  states  that,  “Multiple  changes  were  required  in  the  C-RAM’ s 
program  of  record  (POR)  component  system;  All  such  changes  were  agreed  to  between 
the  C-RAM  and  POR  PMs”  (11).  This  statement  speaks  to  the  ability  of  C-RAM 
stakeholders  to  develop  and  evolve  the  existing  SoS  architecture. 

Along  with  developing  an  SoS  architecture,  it  is  always  important  to  have  a  good 

understanding  of  the  concept  of  operations.  Although  the  C-RAM  was  effective  in  OIF, 

there  were  issues  with  the  collateral  damage  risks  that  occurred  when  using  the  system 

operationally.  It  is  likely  that  these  issues  may  have  been  avoided  if  a  thorough  concept 

of  operations  was  generated  prior  to  the  C-RAMs  deployment.  In  a  general  sense, 

operators  deployed  knowing  their  mission  was  to  warn,  detect,  and  intercept  incoming 

mortars;  however,  extensive  analysis  on  the  effects  of  deploying  the  system  to  theater  did 

not  occur.  One  of  the  characteristics  of  the  C-RAM  is  that  it  fires  many  rounds  at  a  single 

mortar.  In  a  counterinsurgency  environment  where  one  of  the  main  goals  is  to  protect  the 

civilian  population,  protecting  civilians  is  challenging  when  the  C-RAM  is  firing  1 80— 

200  rounds  at  a  mortar.  In  theory,  the  shells  that  do  not  engage  the  mortar  are  supposed  to 

self-destruct  in  the  air;  however,  there  is  always  a  chance  that  shrapnel  from  the  mortars 
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will  endanger  civilians.  As  stated  in  Higgins’  study,  “At  the  tactical  level,  the  clearing  of 
fires  before  the  gun  could  engage  a  hostile  round  resulted  in  failed  interceptions”  (2007, 
27).  The  failed  interceptions  were  a  result  of  the  Anny  not  receiving  clearance  in  time  to 
fire  at  the  incoming  mortars.  This  collateral  damage  issue  might  have  been  understood  in 
greater  detail  if  a  through  concept  of  operations  had  been  in  place.  A  thorough  concept  of 
operations  is  needed  in  order  for  the  system  architecture  to  evolve  with  changing 
environments. 

(6)  Monitoring  and  Assessing  Changes 

The  C-RAM  subordinate  systems  have  had  several  changes  to  the  sensor, 
command  and  control,  and  intercept  systems  (Corbett  2012).  These  changes  were  mostly 
software  changes  that  did  not  have  a  detrimental  effect  on  interoperability  for  the  C-RAM 
system.  However,  training  for  personnel  that  were  manning  the  system  was  difficult 
because  operators  could  not  keep  up  with  developments  in  the  individual  systems 
(Corbett  2012).  Anny  short-range  air  defense  units  took  on  the  majority  of  responsibility 
for  the  C-RAM  mission.  Keeping  up  to  date  on  systems  outside  of  the  Air  Defense 
specific  systems  proved  to  be  challenging.  Personnel  were  not  familiar  with  software 
upgrades  and  had  difficulty  acquiring  necessary  parts  for  the  system.  These  challenges 
are  described  in  the  air  defense  and  field  artillery  Fires  bulletin,  which  states,  “Logistics 
for  the  C-RAM  program  has  grown  in  fits  and  starts  along  the  materiel  domain  path 
where,  initially  it  was  not  keeping  pace  with  the  rapid,  spiral  development  of  the  sensor, 
shooter,  and  command  and  control  equipment  in  the  acquisition  process”  (Corbett  2012, 
53).  This  speaks  to  the  logistical  challenges  that  existed  during  subordinate  systems’ 
evolution.  A  mitigation  that  is  currently  in  place  is  the  transforming  of  two  short-range 
Air  Defense  units  completely  into  C-RAM  units.  This  transformation  will  facilitate 
training  and  build  training  depth  for  the  C-RAM  system.  The  transformation  will  also 
help  with  the  logistical  challenges,  because  dedicated  users  will  be  continuously 
maintaining  the  system  and  becoming  familiar  with  needed  parts. 
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(7)  Addressing  Requirements  and  Solution  Options 

The  C-RAM  system  addresses  the  total  threat  of  incoming  mortars  by  providing 
early  detection,  tracking  ability,  and  intercept  capability.  As  a  result,  the  C-RAM  system 
is  flexible  enough  to  address  a  number  of  requirements  in  varying  operational 
environments.  The  stakeholders’  ability  to  understand  the  requirements  led  to  solutions 
that  met  the  operational  needs  of  the  system.  As  pointed  out  previously,  there  were  issues 
with  the  CONOPS  initially  because  intercepting  mortars  requires  air  and  ground 
clearance,  which  is  not  always  practical,  especially  in  urban  environments.  However,  the 
flexibility  of  the  SoS  found  workable  solutions  to  the  CONOPS  issue.  For  example, 
several  Forward  Operating  Bases  (FOBs)  use  part  of  the  C-RAM  strictly  for  its  early 
warning  capability.  This  capability  allows  personnel  time  to  find  cover  during  an 
incoming  indirect  fire  attack.  Future  iterations  involve  replacing  the  Phalanx  with  a  high 
energy  laser  to  reduce  or  eliminate  the  requirement  for  ground  clearance.  Short-tenn 
developments  for  the  C-RAM  focus  on  addressing  perfonnance  requirements  and 
solutions  through  software  changes,  and  increasing  the  intercept  systems  probability  of 
kill.  In  the  meantime,  the  flexibility  of  the  C-RAM  in  its  current  state  allows  the  system 
to  provide  adequate  solutions  in  a  variety  of  operational  environments. 

(8)  Orchestrating  Upgrades  to  SoS 

One  of  the  challenges  of  the  C-RAM  SoS  has  to  do  with  the  funding  of  the  SoS. 
Each  independent  system  has  its  own  program,  which  means  that  each  system  has  its  own 
line  of  funding  or  POR  (Whaley  and  Stewart  2014).  One  of  the  most  significant  upgrades 
proposed  for  the  C-RAM  system  is  upgrading  the  intercept  system  from  a  shell-  and 
missile-based  system  to  a  laser-based  system.  This  will  improve  accuracy  and  reduce  the 
threat  the  current  system  has  on  personnel,  especially  in  populated  areas.  Funding  still 
has  to  be  captured  in  order  to  responsibly  manage  the  upgrades.  As  Archer  states,  “It  is 
difficult  to  quantify  the  amount  of  funding  that  has  been  directed  to  the  C-RAM  program. 
Funding  has  come  from  multiple  budgets”  (2012,  33).  The  establishment  of  a  program 
director  responsible  for  the  SoS,  as  well  as  the  constituent  systems,  is  currently  leading 
efforts  to  codify  the  funding  for  the  C-RAM  program. 


29 


B.  ARMY  BATTLE  COMMAND  SYSTEM 

The  Army  Battle  Command  System  (ABCS)  is  an  SoS  designed  to  consolidate  the 
U.S.  Anny’s  command  and  control  platfonns.  In  addition,  ABCS  facilitates  the  decision¬ 
maker’s  ability  to  execute  command  and  control  responsibilities,  such  as  planning 
operations  orders,  disseminating  information,  and  assessing  situations.  ABCS  facilitates 
bottom-up  feedback  as  well.  This  can  all  be  done  without  individuals  being  physically 
located  at  the  same  place.  The  constituent  systems  that  make  up  the  SoS  are  as  follows: 


•  Global  Command  and  Control  System  (GCCS):  The  GCCS  system  is  the  link 
between  Anny  tactical  units  and  the  joint  environment.  It  provides  the 
common  operating  picture  link  to  joint  platfonn  (ABCS  Smart  book  2001). 

•  Distributed  Common  Ground  Station-Army  (DCGS-A):  The  DCGS-A  is  a 
comprehensive  intelligence  information  source  for  the  Army  and  joint  force.  It 
provides  surveillance,  a  variety  of  map  overlays  with  imagery,  and  terrain 
analysis.  It  also  provides  access  to  open  source  material  on  the  Internet 
(Department  of  the  Army  2009).  Other  systems  in  the  ABCS  that  provide 
intelligence  data  are  the  digital  topographic  support  system  and  the  integrated 
meteorological  system. 

•  Battle  Command  Sustainment  Support  System  (BCS3):  The  BCS3  is  used  by 
logisticians  to  provide  real-time  logistical  infonnation  and  facilitates  the 
supply  chain  process  with  a  common  operating  picture  for  logistics  at 
different  operational  levels.  (Department  of  the  Army  2009). 

•  Tactical  Airspace  Integration  System  (TAIS):  The  TAIS  provides  situational 
awareness  for  airspace  controllers  at  different  levels.  It  also  facilitates  the 
deconfliction  of  civilian  and  military  assets,  and  provides  a  common  operating 
picture  for  Army  aviation  assets  and  joint  military  assets  in  the  airspace 
(Department  of  the  Anny  2009). 

•  Air  and  Missile  Defense  Workstation  (AMDWS)  and  the  Advanced  Field 
Artillery  Tactical  Data  System  (AFATDS):  These  systems  are  the  C2  nodes 
for  the  Air  Defense  and  Field  Artillery  branches,  respectively  (Department  of 
the  Anny  2009). 

•  Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2):  The  FBCB2  is  the 
main  C2  platform  for  Anny  units  Brigade  level  and  below.  It  provides 
friendly  unit  locations  and  facilitates  the  dissemination  of  operations  orders.  It 
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is  the  link  between  the  brigade  units  and  the  higher  headquarters  (Department 
of  the  Army  2009). 

•  Battle  Command  Common  Services  (BCCS):  This  is  the  server  that  links  the 
constituent  systems  of  the  ABCS  and  provides  interoperability  (Department  of 
the  Army  2009). 


The  diagram  in  Figure  7  depicts  the  ABCS  and  its  constituent  systems. 
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Figure  7.  Army  Battle  Command  Systems  Architecture  (from  DOT&E  2001) 


(1)  Acquisition  Process 

Similar  to  the  C-RAM,  the  ABCS  was  built  using  existing  systems.  It  also  was  an 
acknowledged  SoS  because  the  platforms  were  already  fielded.  One  major  difference  in 
the  acquisition  process  was  that  the  ABCS  process  evolved  from  an  operational 
requirements  document  developed  in  1995  (Department  of  the  Anny  1994).  However,  the 
ABCS  was  not  fielded  as  an  SoS  until  2005.  Prior  to  this  period,  the  ABCS  tenn  was 
used  to  refer  to  the  collection  of  systems  but  lacked  the  integration  of  an  SoS.  The 
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operations  requirements  document  was  part  of  the  Anny  digitization  plan  created  in  1995 
(Department  of  the  Anny  1994).  The  Anny  digitization  plan  included  the  ABCS  common 
operating  environment/common  applications  requirements  document  (Department  of  the 
Army  1994).  This  document  called  for  the  “migration  of  current  separate  Anny  command 
and  control  component  systems  into  one  integrated  system”  (Department  of  the  Army 
1994,  3).  It  called  for  not  only  vertical  integration,  which  would  go  from  the  higher 
headquarters  down  to  the  lowest  level,  but  also  horizontal  integration,  which  allowed 
everyone  in  the  network  to  see  the  commands  instantaneously  (Department  of  the  Anny 
1994). 

(2)  Translating  Capability  Objectives  into  SoS  Requirements 

The  desire  to  integrate  existing  stove-piped  Anny  command  and  control  systems 
into  a  single  integrated  system  drove  the  creation  of  the  SoS  (Department  of  the  Army 
1994).  Around  1995,  there  were  several  individual  systems  such  as  the  FBCB2  and  Blue 
Force  Tracker  (BFT)  being  developed  independently.  The  Program  Executive  Officer 
Command,  Control,  and  Communications  Tactical  (PEO  C3T)  attempted  to  create  an  SoS 
from  these  evolving  systems  (Greene  and  Mendoza  2005).  This  broad  task  was  a 
straightforward  capability  need,  and  the  integration  was  all  network-centric,  as  opposed 
to  an  SoS  for  which  physical  integration  was  necessary.  The  challenge  that  stemmed  from 
translating  capability  objectives  into  requirements  was  addressed  by  the  Chief  of  Staff  of 
the  Army  (CSA)  of  the  Anny  in  2003.  He  realized  that  most  of  the  individual  C2 
platforms  being  developed  were  based  on  bottom-up  infonnation  (Greene  and  Mendoza 
2005).  Many  of  the  individual  systems,  such  as  the  FBCB2,  were  created  to  pull 
information  from  subordinate  units.  In  the  case  of  the  FBCB2,  subordinate  units  would 
usually  communicate  their  location  through  radio,  and  a  member  of  the  Army  staff  would 
update  their  location  on  the  map.  The  CSA  realized  the  need  for  a  top-down  approach  to 
the  ABCS  acquisition.  This  would  mean  that  requirements  would  be  looked  at  from  the 
service  and  joint  levels  (Greene  and  Mendoza  2005).  This  top-down  approach  helped  to 
lay  the  groundwork  for  the  SoS  architecture  that  currently  exists. 
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(3)  Understanding  the  Constituent  Systems  and  Their  Relationships 

One  of  the  positive  things  about  the  initial  bottom-up  development  of  ABCS 
constituent  systems  was  that  it  allowed  users  at  the  lowest  level  to  become  familiar  with 
the  system.  This  familiarity  led  to  increased  and  valuable  user  feedback  when  the 
individual  systems  were  being  developed.  As  stated  in  the  article  by  Greene  and 
Mendoza,  “Development  of  ABCS  6.4  is  proceeding  from  the  warfighter’s  perspective 
and  incorporates  user  feedback  that  defines  69  operational  good  enough  requirements” 
(2005,  201).  Incorporating  users  at  the  lowest  level  created  a  broad  knowledge  base  of 
individuals  on  their  respective  systems,  which  facilitated  the  understanding  of  the 
relationship  between  systems.  Another  point  is  that  all  of  the  subordinate  systems  were 
specific  to  a  particular  Army  branch.  For  example,  the  AMDWS  was  created  based  on  the 
tactical  needs  of  the  Air  Defense  branch;  the  AFATDS  was  based  on  the  tactical  needs  of 
the  field  artillery.  The  Army  at  the  time  had  a  lot  of  experience  with  combined  operations 
from  exercises  and  previous  conflicts,  so  understanding  the  relationships  between 
platforms  was  easier  for  this  reason  as  well. 

(4)  Assessing  Performance  to  Capability  Objectives 

As  previously  mentioned,  the  incorporation  of  user  feedback  was  a  significant 
factor  in  the  ABCS  acquisition.  This  as  well  as  testing  had  a  positive  impact  on  assessing 
the  ABCS  performance.  Additionally,  in  2003,  the  CSA  established  metrics  for  where  the 
ABCS  should  focus  their  efforts.  These  metrics  centered  on  the  following  areas: 

•  Friendly  Locations 

•  Current  Enemy  Situation 

•  Running  Estimate 

•  Graphic  Control  Measures 

•  Fragmentary  Orders 

•  Commanders  Situation  Report 

•  Fire  Support  Coordination  Measures/Capabilities  Overlay 

•  Joint  and  Coalition  Interoperability 

(Greene  and  Mendoza  2005) 
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There  was  a  lot  of  information  contained  in  all  of  these  systems.  When  the  CSA 
focused  on  these  areas  for  performance,  it  made  it  a  lot  easier  to  assess  the  perfonnance 
against  capability  objectives.  The  CSA  wanted  to  establish  a  system  that  was  “good 
enough”  for  fielding  (Greene  and  Mendoza  2005). 

(5)  Developing  and  Evolving  an  SoS  Architecture 

Developing  the  SoS  architecture  for  the  ABCS  was  challenging  for  the  Army. 
Individual  systems  were  already  fielded  in  the  respective  Army  branches.  Additionally, 
Army  doctrine  such  as  the  Military  Decision-Making  Process  (MDMP)  required  Army 
staff  at  high  levels  to  conceptually  integrate  infonnation  from  different  Anny  branches 
(Frambes  2005).  Conceptually,  most  of  the  analysis  required  to  develop  an  SoS  structure 
had  already  been  completed.  However,  the  transition  from  a  stovepipe  process  to  an  SoS 
process  created  challenges  when  trying  to  create  a  networked  architecture.  As  stated  by 
Greene  and  Mendoza,  “ABCS  6.4  good  enough  was  moving  from  a  loosely  coupled 
architecture  to  a  tightly  coupled  SOS  architecture,  but  too  often,  issues  and  problems 
were  perceived  as  individual  software  releases  geared  to  stovepipe  solutions”  (2005, 
206).  This  challenge  was  mitigated  by  the  establishment  of  several  integrated  product 
teams  (IPTs)  that  focused  on  SoS  development  in  several  different  areas. 

(6)  Monitoring  and  Assessing  Changes 

Once  the  ABCS  was  established  as  an  SoS,  individual  systems,  such  as  the 
Command  Post  of  the  Future  (CPOF),  were  created  to  be  interoperable  with  the  ABCS. 
Even  though  the  CPOF  was  developed  as  an  individual  system,  one  of  the  requirements 
for  it  to  become  a  program  of  record  was  to  establish  interoperability  with  the  ABCS 
(Greene  2010).  Other  systems,  such  as  the  DCGS-A,  which  is  the  intelligence  tool  that 
evolved  from  the  All  Source  Analysis  System  (ASAS),  followed  a  similar  pattern.  The 
IPTs  were  also  instrumental  in  monitoring  and  assessing  system  changes.  They  ensured 
that  major  software  upgrades  for  the  ABCS  were  coordinated  through  individual  systems. 
The  ABCS  has  transitioned  to  a  Publish  and  Subscribe  Server  (PASS)  system  and  made 
more  than  four  major  software  updates  without  degrading  the  individual  systems’ 
capabilities  (Greene  2010). 
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(7)  Addressing  Requirements  and  Solution  Options 

The  ABCS  had  the  benefit  of  operational  testing  at  the  SoS  level.  As  shown 
earlier,  SoS  testing  is  extremely  difficult  due  to  individual  systems  being  in  different 
levels  of  maturity  and  different  stages  of  the  acquisition  process.  ABCS  SoS  testing  led  to 
the  identification  of  requirements  outside  the  scope  of  individual  systems,  and  proposed 
solution  options  for  the  SoS  as  a  whole.  As  stated  in  the  Directorate  of  Operational  Test 
and  Evaluation  (DOT&E)  pamphlet,  “The  ABCS  SoS  assessment  contributed  valuable 
insights  to  the  evaluations  of  the  individual  acquisition  programs.  By  taking  a  more 
holistic  approach,  the  assessment  identified  significant  issues  beyond  the  scope  of  a 
single  program  manager’s  responsibility”  (2005,  46).  This  suggests  that  the  SoS  testing 
addressed  SoS  requirements  and  also  addressed  individual  system  issues  to  help  meet 
individual  system  requirements.  The  results  of  this  testing  led  to  proposed  solutions  that 
addressed  SoSs  as  well  as  individual  system  requirements.  It  also  underscored  the  fact 
that  with  SoS,  testing  of  the  entire  SoS  produces  results  that  cannot  be  obtained  from 
testing  systems  individually.  These  recommendations  included  an  improved  network 
architecture,  increased  network  security,  and  funding  for  collective  training  (DOT&E 
Army  Programs  2005,  46).  Testing  also  led  to  the  development  of  the  central  infonnation 
server  that  exists  with  the  system  today. 

(8)  Orchestrating  Upgrades  to  SoS 

In  2004,  the  Army  decided  to  change  the  direction  of  the  ABCS  development 
from  a  bottom-up  approach  to  a  top-down  approach.  During  this  time  the  Anny  also 
refocused  and  reprioritized  the  desired  capabilities  for  the  ABCS.  The  PEO  organized  the 
Army  stakeholders  into  several  IPTs  and  established  what  he  tenned  as  “good  enough” 
requirements  for  the  IPTs  to  achieve  in  the  6.4  version  of  ABCS  (Greene  and  Mendoza 
2005,  206).  The  good  enough  requirements  were  important  because  they  provided  a 
capability  while  acknowledging  that  the  SoS  would  not  be  fully  mature  with  version  6.4. 
This  iterative  approach  to  development  encourages  developers  to  design  systems  and 
architectures  that  could  be  upgraded  easily  in  the  future  without  major  changes  to  the 
system  architecture.  Since  2005,  the  ABCS  has  successfully  added  new  systems,  such  as 

the  CPOF,  and  the  ABCS  is  becoming  part  of  a  broader  Anny  initiative  called  Capability 
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Set  13  (CS-13).  Capability  Set  13  and  those  that  follow  will  significantly  increase  the 
network  capacity  of  the  ABCS,  and  add  platforms  for  the  dismounted  soldier  to  access 
information  provided  by  the  ABCS.  This  ability  to  orchestrate  upgrades  was  enhanced  by 
the  decision  to  incrementally  field  systems  while  keeping  upgrades  in  mind. 

C.  FUTURE  COMBAT  SYSTEMS 

The  Army  Future  Combat  Systems  (FCS)  represents  the  biggest  SoS  undertaking 
that  the  Anny  has  ever  attempted.  The  idea  started  in  1999  and  large  portions  of  the 
program  were  cancelled  by  2009.  The  Anny  FCS  was  a  directed  SoS  intended  to 
completely  change  the  way  the  Anny  fought  wars.  The  idea  originated  from  then  Army 
Chief  of  Staff  General  Shinseki.  His  intent  was  to  take  the  existing  Anny  division 
structure  and  transfonn  it  to  a  lighter,  more  mobile  force  that  could  deploy  a  division¬ 
sized  unit  in  five  days  (Feickert  2009).  The  SoS  would  take  existing  Army  platforms  and 
integrate  these  platfonns  into  a  large  network  that  would  be  consistent  throughout  the 
whole  Army.  The  FCS  was  the  largest  acquisition  project  the  Anny  ever  attempted  in 
tenns  of  cost.  It  was  also  the  first  time  that  the  Anny  initiated  an  SoS;  usually  the  Army 
would  identify  a  capability  gap  and  build  a  system  or  combine  systems  to  meet  this 
capability  gap.  The  FCS  was  the  first  directed  SoS  for  the  Army.  The  FCS  consisted  of 
four  systems:  the  manned  FCS  ground  systems,  unmanned  air  vehicles,  unmanned 
ground  vehicles,  and  sensors/weapons.  Table  3  describes  the  typical  equipment  that 
would  be  organic  to  an  FCS  Brigade. 
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Table  3.  Army  FCS  Brigade  Equipment  List  (from  Congressional  Budget 

Office  2006,  30) 


Planned  New  Components  for  an 
FCS-Ecpiipped  Brigade 

Quantity* 


Manned  Systems 

Mounted  Combat  System  60 

Infantry  Carrier  Vehicle  102 

Command-and-Control  Vehicle  49 

Reconnaissance  and  Surveillance  Vehicle  30 

Non-Line-of-Sight  Mortar  24 

Non-line-of-Sight  Cannon  18 

Medical  Vehicle  29 

Recovery  and  Maintenance  Vehicle  10 

Unmanned  Ground  Vehicles 

Armed  Robotic  Vehicle-Assault  18 

Armed  Robotic  Vehicle-Reconnaissance, 

Surveillance,  and  Target  Acquisition  27 

Armed  Robotic  Vehicle-Assault  (tight)  18 

Multifunctional  Utility,  Logistics,  and 
Equipment  Vehicle  90 

Small  Unmanned  Ground  Vehicle  81 

Unmanned  Aerial  Vehicles 
(Launch  and  Control  Units/ Aircraft) 

Class  I  54/108 

Class  n  36/36 

Class  m  12/48 

Class  IVa  2/8 

Class  IVb  8/16 

Other 

Unattended  Ground  Sensors  136 

Non-Line-of-Sight  Launch  System  60 

Intelligent  Munitions  System  30  or  88B 


All  of  the  subsystems  in  the  manned  systems  category  were  designed  to  be  lighter 
and  faster  versions  of  Anny  legacy  systems.  For  example,  the  mounted  combat  system 
(MCS)  was  intended  to  be  a  lighter  and  faster  version  of  the  Abrams  tank  with  equivalent 
firepower  (Congressional  Budget  Office  [CBO]  2006).  The  infantry  carrier  vehicle  (ICV) 
would  replace  the  Bradley  fighting  vehicle  and  Ml  13  personnel  carriers.  The  ICV  would 
also  be  lighter  and  faster  than  the  Bradley  with  increased  firepower.  Similarly,  the  non¬ 
line  of  sight  mortar  and  cannon  (NLOS-M/C)  would  replace  the  M-113  and  M109 
howitzer,  respectively  (CBO  2006).  The  recovery  and  maintenance  vehicle  would  replace 
the  M88  recovery  vehicle  (CBO  2006).  The  unmanned  ground  vehicle  system  was  split 
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into  four  classes,  and  each  class  would  be  designed  to  support  a  specific  Army  force  size. 
The  class  I  UAVs  would  be  designed  for  the  individual  soldier,  the  class  II  UAVs  would 
support  a  company-sized  element,  the  class  III  UAVs  would  support  a  battalion-sized 
element,  and  the  class  IV  UAVs  would  support  a  brigade-sized  element  (CBO  2006).  The 
unmanned  aerial  UAVs  were  divided  into  a  similar  class  structure  as  the  unmanned 
ground  system,  and  they  supported  the  same-sized  unit.  The  unmanned  sensor  and  fire 
systems  would  be  designed  to  increase  intelligence  and  initiate  fires  via  remote  control. 
Figure  8  shows  the  FCS  SoS  and  its  constituent  systems. 


Mounted 
Combat  Systom 


Manned  Systems 


Unmanned  Air  Vehicles 


& 


Class  I 


Class  II  Class  III 


Claes  IV 


Surveillance  Vehicle 


Unattended 
Ground  Sene 


Unattended 
Munitions 

•  Nl  OS  1  S 

•  Intelligent 

|J  Munitions 

°"  System 


Unmanned  Ground  Vehicles 


Non-Line- 
of-Slght  Cannon 


FCS  Recovery  and 
Maintenance  Vehicle 


Medical  Treatment 
and  Evacuation 


Armed 
Robotic  Vehicle 
ARV  RSTA 
ARVAsIt 


Small  ^ 

(Manpackable)" 
UGV 


nicie  a 

ARV-A(L)  MULE:  ^  MULE' 

(Countermine)  (Transport) 


Figure  8.  Army  FCS  SoS  (from  Global  Security.Org  2011) 


(1)  FCS  Acquisition 

The  FCS  acquisition  plan  was  a  long-term  but  aggressive  plan  to  get  the  entire 
Army  transformed  by  the  year  2032  (Feickert  2009).  The  plan  called  for  seventy-one 
Army  Brigades,  each  having  eighteen  systems  fielded  by  2032.  It  was  soon  realized  that 
this  schedule  could  not  be  maintained  and  several  changes  occurred,  including  reducing 
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the  number  of  simultaneously  fielded  systems  from  eighteen  to  fourteen,  and  program 
restructuring  that  occurred  in  2004  (CBO  2006).  This  also  reduced  the  number  of  systems 
that  were  simultaneously  fielded.  There  were  several  contractors  on  the  FCS  project  as 
well.  DARPA  was  one  of  the  primary  contractors,  and  they  worked  with  the  lead  system 
integrator  (LSI)  team  of  Boeing  and  SAIC  (Gansler  2009).  Much  of  the  work  was 
subcontracted  as  well.  This  proved  to  be  a  challenge  when  trying  to  test  and  integrate 
systems  at  the  SoS  level.  Further,  the  cost  of  the  FCS  was  intended  to  be  roughly  $200 
billion  for  research  and  development  and  procurement  (CBO  2006).  However,  during  the 
program’s  first  four  years,  the  program  experienced  cost  growth  between  sixty-nine  to 
100  billion  dollars  more  than  initially  estimated.  The  increasing  cost  growth  without 
substantial,  tangible  results  led  to  the  program’s  cancellation  in  2009  (Cordesman  2009). 
Looking  at  the  core  concepts  of  SoS  engineering  will  provide  some  insights  into  potential 
reasons  for  why  the  program  was  canceled. 

(2)  Translating  Capability  Objectives 

The  FCS  program  had  a  broad  capability  to  make  the  Anny  “more  responsive, 
lethal,  versatile,  survivable,  and  sustainable”  (Pernin  et  al  2012,  9).  Although  SoS 
capability  objectives  must  be  broad  enough  to  generate  SoS  requirements,  the  capability 
objectives  described  for  the  FCS,  such  as  lethality  and  versatility,  were  broad  enough  to 
generate  multiple  SoSs.  The  FCS  was  expected  to  address  all  of  these  warfighting 
functions  simultaneously.  Although  the  initial  objectives  were  broad,  when  they  were 
translated  into  requirements,  they  became  very  specific  down  to  the  system  level.  There 
must  be  a  delicate  balance  between  requirements  that  are  specific  enough  to  meet  the 
objectives,  but  not  so  specific  that  they  impact  the  generation  of  alternatives  for  the  SoS. 
In  the  case  of  the  FCS,  requirements  significantly  reduced  the  design  space  for  the  SoS. 
An  example  of  this  can  be  seen  from  the  C-130  requirement.  All  FCS  systems  were 
required  to  be  C-130  deployable.  This  was  considered  a  non-negotiable  requirement 
(Pemin  et  al  2012).  As  a  result,  this  requirement  would  impact  the  size  and  weight  of  all 
the  platforms  being  designed.  Although  the  increase  in  time  and  money  was  not 
quantified,  this  requirement  likely  resulted  in  unnecessary  additional  costs  and  time;  the 
Army  has  other  air  assets  available  that  could  be  used  to  air  transport  the  FCS.  As  the 
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FCS  progressed,  the  restrictive  nature  of  the  C-130  requirement  became  apparent.  Efforts 
to  try  and  change  this  requirement  would  prove  difficult,  as  evidenced  by  the  RAND 
report  which  states  that  removing  the  C-130  requirement  “would  have  introduced  major 
inconsistencies  into  the  overarching  plan,  which  made  that  requirement  difficult  to  revise 
without  overturning  fundamental  notions  about  how  FCS  would  fight”  (Pernin  et  al  2012, 
58).  The  requirement  was  eventually  relaxed  a  few  years  later. 

(3)  Understanding  Systems  and  Relationships 

The  FCS  platfonns  were  primarily  based  on  existing  systems.  For  example,  the 
MCS  was  centered  on  maneuver  vehicles  such  as  the  Abram  and  Bradley  vehicles.  The 
unmanned  aerial  and  ground  vehicles  were  designed  to  support  specific  force  sizes  in  the 
Anny.  As  a  result,  clear  system  boundaries  were  established  for  each  of  the  platforms, 
and  their  relationships  with  other  systems  were  also  clearly  understood  because  legacy 
versions  of  the  platfonns  already  existed,  and  new  platforms  fell  within  the  boundaries  of 
existing  Army  force  structure.  For  example,  there  were  unmanned  vehicles  designed  to 
support  the  individual,  company,  battalion,  and  brigade  levels.  The  challenge  arose  when 
trying  to  understand  network  system  boundaries.  The  FCS  was  required  to  be  completely 
interoperable  (Davis  and  Bagwell  2004).  Each  platfonn  would  have  the  capability  to  pass 
information  to  other  platforms.  The  approach  to  accomplish  this  networked  activity  was 
to  build  platforms  only  after  they  had  demonstrated  the  ability  to  communicate  with 
existing  platfonns.  Evidence  of  the  interoperability  requirement  is  illustrated  in  an  SoS 
integration  report,  which  states:  “Specific  FCS  systems  will  be  procured  only  after  four 
dimensions  of  integration  are  demonstrated — vertical,  horizontal,  performance  and 
interoperable”  (Davis  and  Bagwell  2004,  17).  The  vertical  and  horizontal  dimensions 
minor  the  Army’s  expectations  for  communication  on  the  battlefield.  For  example,  a 
brigade  level  system  must  be  able  to  communicate  with  its  subordinate  battalion  level 
systems.  Horizontal  communications  refer  to  systems  at  the  battalion  level  being  able  to 
communicate  with  other  battalion  level  systems.  Perfonnance  and  interoperability  are 
based  on  metrics  defined  in  the  requirements.  The  four-dimension  integration  proved  to 
be  challenging  because  there  were  several  different  contractors,  such  as  Boeing,  General 
Dynamics,  DARPA,  and  SAIC,  working  on  the  platforms.  This  approach  to  integrating 
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the  platforms  did  not  demonstrate  a  true  understanding  of  systems  and  boundaries 
because  each  of  these  contractors  has  its  own  agenda  and  its  own  information  which  it 
may  be  unwilling  to  share.  The  different  contractors  involved  that  were  supposed  to 
collaborate  did  not  collaborate  enough  to  build  the  type  of  SoS  that  the  Army  envisioned. 

(4)  Assessing  Performance  to  Capability  Objectives 

Assessing  the  performance  to  capability  objectives  was  challenging  because  the 
FCS  was  such  a  massive  project  (Pemin  et  al  2012).  The  FCS  was  designed  to  address 
future  capabilities  by  upgrading  old  systems.  As  a  result,  several  assumptions  were 
necessary  to  build  the  system.  As  stated  in  the  Pernin  RAND  study,  one  assumption  that 
had  a  profound  impact  on  assessing  perfonnance  to  capability  was  that  the  U.S.  Anny 
would  be  engaged  in  state-to-state  conflicts.  While  there  was  some  insurgency  in  one 
particular  scenario,  most  of  the  scenarios  focused  on  state-to-state  actors  (Pemin  et  al 
2012).  Another  assumption  was  that  the  capabilities  for  conventional  warfare  would  be 
sufficient  to  combat  insurgent  warfare.  The  focus  on  state-to-state  actors  framed  the 
context  for  which  the  SoS  was  evaluated  against  capabilities.  A  few  years  later,  in  2004 
and  beyond  when  the  United  States  faced  insurgencies  in  both  Afghanistan  and  Iraq,  the 
FCS  was  disconnected  with  the  current  threat.  The  FCS  depended  almost  completely  on 
simulation  testing  to  assess  performance  to  capabilities  (Pemin  et  al  2012).  While 
simulation  is  a  cost-effective  tool,  it  does  not  always  yield  accurate  results  on  how  the 
system  will  perfonn,  because  models  are  only  as  good  as  their  inputs  and  the  validity  of 
the  model  assumptions.  Assessing  the  perfonnance  was  shaped  by  assumptions  that  were 
not  necessarily  true.  As  a  result,  the  FCS  program  conducted  testing  and  evaluation  based 
on  invalid  assumptions,  which  led  to  an  inaccurate  assessment  of  perfonnance  to 
capability  objectives. 

(5)  Developing  and  Evolving  an  SoS  Architecture 

Individual  system  requirements  for  FCS  systems  were  conducted  in  conjunction 
with  SoS  system  requirements.  This  dual  development  made  it  difficult  to  establish  a 
system  architecture  at  the  SoS  level.  As  alluded  to  in  the  RAND  study,  systems 
engineering  was  being  conducted  at  the  system  level.  During  this  process,  trade-offs  were 
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also  conducted  at  the  system  level  without  taking  SoS  level  requirements  into 
consideration  (Pernin  2012).  This  suggests  that  the  individual  systems  had  a  significant 
impact  on  the  intended  SoS  architecture.  The  individual  systems  were  so  complex  that  by 
the  time  the  systems  were  considered  in  the  context  of  an  SoS,  the  trade-offs  would  be 
costly  in  perfonnance,  schedule,  or  dollars  to  make  any  changes  that  facilitated  the  SoS 
development.  There  is  no  evidence  suggesting  that  any  detailed  SoS  architecture  was 
conducted  early  in  the  SoS  development.  Ideally,  for  a  directed  SoS,  an  SoS  architecture 
should  be  completed  first  so  that  individual  systems  can  maintain  an  SoS  perspective 
when  designing  and  building  individual  systems.  This  was  not  the  case  for  the  FCS. 
Without  a  baseline  architecture,  individual  systems  were  designed  independently  and 
then  expected  to  integrate  with  existing  systems.  This  type  of  approach  is  more 
appropriate  for  an  acknowledged  SoS  system.  In  an  acknowledged  SoS,  the  platfonns 
already  exist,  and  therefore  a  bottom-up  approach  is  necessary.  In  an  acknowledged  SoS, 
most  individuals  are  familiar  with  the  existing  systems  so  it  is  easier  to  suggest  trade-offs 
and  come  up  with  ways  for  systems  to  be  interoperable.  In  the  case  of  the  FCS,  the  SoS 
was  directed  but  approached  from  the  bottom  up  as  if  the  systems  were  already  in  place. 
Further  evidence  of  the  issues  with  this  bottom-up  approach  is  described  in  the  RAND 
study,  which  states: 

Often  it  was  difficult  to  understand  exactly  how  individual  requirements 
interacted  with  one  another  and  fit  into  the  operational  architecture,  which 
was  relatively  underdeveloped  and  reportedly  marginalized  as  the  program 
focused  on  preparing  the  ORD  for  JROC  approval  to  pass  Milestone  B. 

(Pemin  et  al  2012,  93) 

(6)  Monitoring  and  Assessing  Changes 

As  previously  stated,  the  acquisition  budget  grew  by  almost  $100  billion  over 
three  years.  During  that  time  period  and  a  couple  of  years  prior,  several  changes  took 
place  in  the  FCS  program  that  was  not  accurately  assessed.  According  to  a  Center  for 
Strategic  and  International  Studies  (CSIS)  report,  budget  constraints  led  to  the  reduction 
of  four  FCS  constituent  systems.  Although  it  was  intended  to  reduce  cost,  there  was  no 
change  in  the  budget  to  reflect  this  reduction  (Cordesman  2009).  One  of  the  characteristic 
traits  of  the  FCS  acquisition  was  that  developers  did  not  seem  to  understand  how  external 
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SoS  changes  such  as  program  cuts  would  impact  the  system.  Some  of  this  stemmed  from 
not  having  an  SoS  architecture,  and  part  of  it  stemmed  from  the  lack  of  understanding  of 
how  new  systems  would  be  interoperable  with  one  another.  Requirements  changes  also 
were  difficult  to  assess.  As  each  system  developed  independently  with  its  own 
requirements,  when  changes  were  necessary  to  accommodate  the  SoS,  they  often 
occurred  slowly  and  sometimes  at  a  cost  (Cordesman  2009).  These  costs  led  to  system 
cost  and  schedule  growth  without  any  significant  system  development  progress. 

In  the  early  stages  of  the  Iraq  and  Afghanistan  war,  there  was  a  notable  difference 
in  the  insurgency  the  coalition  force  was  fighting  and  the  type  of  operations  the  FCS  was 
being  designed  to  accomplish.  To  mitigate  this  discrepancy,  the  FCS  changed  the 
acquisition  strategy  to  adapt  to  the  changing  environment  in  these  theaters.  These  “spin¬ 
out”  technologies  would  go  directly  to  the  soldiers  on  the  ground  and  have  a  separate 
development  schedule  than  the  FCS  (Pemin  et  al.  2012).  These  spin  outs  led  to  the 
development  of  some  UAVs  and  unmanned  ground  systems.  However,  as  the  RAND 
study  points  out,  these  spin  outs  were  not  part  of  the  original  plan  and  added  to  the  cost, 
and  delayed  the  schedule  (Pemin  et  al  2012).  The  long-tenn  FCS  project  was 
transforming  into  both  a  long-  and  short-tenn  project  without  the  staff  to  support  such  a 
change.  As  stated  in  the  RAND  study,  “Interviews  with  officials  highlighted  how  the 
spin-outs  took  valuable  time  from  certain  participants  in  the  program  who  would 
otherwise  be  thinking  about  longer-tenn  development  issues  and  requirements”  (Pernin  et 
al  2012,  38). 

(7)  Addressing  SoS  Requirements  and  Solution  Options 

The  issue  of  requirements  at  the  system  level  and  the  SoS  level  has  been 
addressed  extensively  in  this  paper.  These  issues  stemmed  from  the  development  of 
individual  systems  without  an  SoS  perspective.  Another  aspect  of  the  requirements  was 
the  validation  process  for  the  FCS  program.  Due  to  General  Shinseki’s  eagerness  to  begin 
fielding  the  system  as  quickly  as  possible,  the  FCS  program  did  not  go  through  the 
rigorous  requirements  validation  programs  that  normal  acquisition  programs  go  through 
(Bradford  2011).  The  FCS  bypassed  key  senior  Army  leaders  who  may  have  been  able  to 
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add  valuable  input  to  the  requirement  generation  process.  As  a  result,  several  changes  had 
to  occur  after  time  was  spent  building  to  requirements  that  had  not  been  properly  vetted. 

The  FCS  was  intended  to  move  the  Army  into  the  future.  As  stated  earlier,  most 
of  the  requirements  were  geared  toward  operating  the  FCS  in  a  conventional  war. 
However,  during  development  an  unconventional  war  was  occurring,  which  caused  the 
FCS  to  change  its  acquisition  strategy  to  accommodate  the  ongoing  conflict.  It  is  difficult 
to  find  solution  options  if  the  problem  keeps  changing.  In  the  case  of  the  FCS,  the 
problem  the  FCS  was  originally  optimized  to  address  changed  significantly.  This  often 
leads  to  scope  creep  and  a  suboptimal  solution  to  multiple  problems.  The  FCS  was 
heading  down  that  road  before  it  was  cancelled  in  2009. 

(8)  Orchestrating  SoS  Upgrades 

In  2009,  then  Secretary  of  Defense  Robert  Gates  made  the  decision  to  cancel  the 
FCS  program.  Although  the  FCS  as  an  SoS  never  came  to  fruition,  the  FCS  efforts  led  to 
successful  spin-off  systems.  For  example,  a  lot  of  the  technology  used  for  the  Maneuver 
control  subsystem  was  used  to  develop  the  Anny’s  current  Ground  Combat  Systems 
(GCS)  (Pemin  et  al  2012).  Further,  much  of  the  technology  used  to  develop  unmanned 
ground  and  air  vehicles  was  salvaged  and  fielded  in  places  like  Iraq  and  Afghanistan. 
Additionally,  on  a  smaller  scale  some  of  the  network  architecture  was  used  for  future 
systems.  Other  potential  spinoffs  likely  did  not  take  place  due  to  the  Anny  having  to 
spend  nearly  one  billion  dollars  to  cancel  existing  contracts. 

D.  SUMMARY  OF  CASE  STUDY  LESSONS  LEARNED 

The  following  lessons  learned  have  been  obtained  from  the  three  case  studies. 
These  lessons  learned  will  be  used  in  Chapters  IV  and  V  to  recommend  process  and 
organizational  changes  respectively. 

(1)  Lesson  #1:  Leverage  the  JUONS  process  for  urgent  need  SoSs. 

The  complexity  of  the  acquisitions  process  often  results  in  the  belief  that  all  SoS 
acquisitions  will  be  complex  efforts  that  take  a  significant  amount  of  time  to  go  through 
the  acquisition  process.  From  the  C-RAM,  one  can  note  that  an  SoS  acquisition  does  not 
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necessarily  have  to  be  a  long-term  acquisition  process,  especially  when  dealing  with  an 
acknowledged  SoS.  The  C-RAM  was  able  to  use  existing  platforms  and  provide  a  partial 
solution  to  the  incoming  mortar  problem  within  fifteen  months  of  the  problem  being 
identified.  The  process  started  with  a  JUONS  that  specifically  addresses  urgent  threats. 
The  C-RAM  is  an  example  of  how  this  process  can  be  leveraged  for  SoSs  as  well  as 
individual  systems.  Using  the  JUONS  process  or  an  abbreviated  acquisition  process  for 
directed  SoSs  is  difficult,  and  should  not  be  done  unless  absolutely  necessary.  The  FCS 
illustrates  an  example  of  the  potential  pitfalls  of  abbreviating  the  acquisition  process  for  a 
directed  SoS. 

(2)  Lesson  #2:  Establishing  a  strong  link  from  a  needs  statement  to  an  SoS 
architecture  to  CONOPS  development  is  essential. 

The  C-RAM  also  illustrates  the  importance  of  creating  a  need  statement  for  SoS 
that  is  specific  enough  to  meet  the  need,  but  general  enough  to  generate  enough 
alternatives  to  choose  from.  Additionally,  the  C-RAM  underscored  the  importance  of  an 
SoS  architecture  that  develops  an  OV-1  at  a  minimum.  The  OV-1  will  facilitate  a  concept 
of  operation  for  the  SoS.  This  is  important  because  it  forces  decision  makers  to  think 
about  how  the  SoS  will  work  together,  and  it  identifies  problems  in  the  early  stages  of 
development.  The  C-RAM  underscored  the  need  for  a  thorough  logistics  plan  that  is 
generated  from  the  CONOPS.  An  SoS  will  have  a  lot  of  components,  so  it  is  important 
that  a  logistical  plan  is  in  place  to  carry  the  SoS  through  the  life  cycle  of  various 
CONOPS.  Moreover,  the  C-RAM  demonstrated  the  importance  of  setting  up  an 
architecture  that  facilitates  upgrades.  The  C-RAM  SoS  conducted  several  software 
upgrades  as  well  as  platfonn  upgrades  without  major  SoS  configuration  changes.  One 
must  always  look  to  future  integration  and  interoperability  requirements  when 
establishing  architecture  for  an  SoS. 

The  FCS  program  used  simulations  to  analyze  the  concept  of  operations. 

However,  most  of  the  simulations  were  based  on  conventional  operations  that  the  United 

States  was  used  to  fighting.  A  diagrammed  SoS  architecture,  such  as  the  SoS  DODAF 

models,  could  have  led  to  a  broader  view  of  SoS  capabilities,  and  possibly  could  have 

placed  more  emphasis  on  unconventional  wars,  such  as  the  insurgencies  in  Iraq  and 
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Afghanistan.  The  FCS  program  instead  made  program  changes  after  a  significant  amount 
of  money  was  already  spent. 

(3)  Lesson  #3:  Limit  the  scope  of  objectives  for  the  SoS  during  a  single 
iteration. 

The  FCS  demonstrates  the  difficulty  of  implementing  platform  and  network 
integration  and  interoperability  in  one  iteration.  During  the  FCS  acquisition,  platforms 
were  built  and  then  used  to  integrate  with  existing  systems.  This  caused  a  significant 
delay  in  the  development  schedule.  Directed  SoSs  should  normally  build  the  platforms 
during  early  iterations,  and  then  use  future  iterations  for  integration  and  interoperability. 
The  SoS  wave  model  is  discussed  in  the  following  chapter  but  one  of  the  benefits  of  the 
SoS  wave  model  is  that  it  focuses  on  the  evolution  of  the  SoS  so  that  iterations  of 
development  can  be  planned  and  resourced  appropriately.  The  ABCS  acquisition  used  a 
limited  set  of  objectives  for  the  initial  SoS.  Although  there  were  many  goals  for  the  final 
system,  the  CSA  focused  on  eight  central  objectives  before  the  system  was  fielded.  Often, 
a  workable  solution  can  be  fielded  when  objectives  are  prioritized.  This  would  expedite 
the  acquisition  process  for  SoS.  Using  the  wave  model  and  developing  an  architecture 
early  in  the  acquisition  process  will  lead  to  an  effective  balance  of  scope  and  time. 
Limiting  the  scope  will  enable  stakeholders  to  field  workable  solutions  in  the  short-term, 
while  aiming  to  achieve  optimal  long-tenn  solutions  on  future  SoS  iterations. 

(4)  Lesson  #4:  Use  a  bottom-up  approach  for  an  acknowledged  SoS. 

SE  and  SoS  SE  are  both  top-down  processes.  It  is  important  that  the  SoS  goals  are 
clearly  articulated  at  an  SoS  level  before  attempting  to  build  an  SoS.  However,  in  an 
acknowledged  SOS,  it  may  be  appropriate  to  generate  requirements  using  a  bottom-up 
approach  for  existing  systems.  A  bottom-up  approach  looks  at  the  individual  system  and 
explores  relationships  with  other  systems  in  order  to  create  an  SoS  from  existing  systems. 
The  advantage  of  this  bottom-up  process  is  that  it  can  increase  capabilities  without 
initiating  the  JCIDS  process.  This  bottom-up  approach  will  lead  to  increased  capabilities, 
and  increased  connectivity  with  existing  systems.  The  ABCS  used  the  bottom-up 
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approach  effectively  during  testing,  and  incorporated  a  lot  of  the  user  feedback  from 
individual  systems  to  generate  SoS  requirements. 

(5)  Lesson  #5:  Align  SoS  boundaries  with  organizational  boundaries  if 
possible. 

An  SoS  has  complex  physical  and  virtual  boundaries  that  could  potentially  lead  to 
scope  creep  in  the  acquisition  process  if  not  understood  properly.  An  important  point 
when  creating  an  SoS  is  to  try  and  use  existing  organizational  boundaries  for  initial  SoS 
development.  If  the  subordinate  system  boundaries  correspond  to  an  organizational 
boundary  in  the  Anny,  such  as  a  system  that  is  specific  to  one  Army  branch,  it  will  be 
easier  to  understand  how  systems  interact  with  each  other,  because  it  will  be  similar  to 
existing  organizational  boundary  interactions.  For  example,  in  the  ABCS,  the  Air 
Defense  Artillery  and  Field  Artillery  use  the  AMDWS  and  the  AFATDS,  respectively. 
These  Anny  branches  have  experience  with  combined  arms  warfare,  and  this  combined 
arms  experience  led  to  a  better  understanding  of  how  the  ABCS  constituent  systems 
should  interact  at  an  SoS  level.  Using  existing  organizational  boundaries  as  the  basis  for 
SoS  development  leads  to  better  understanding  of  the  interactions  that  must  take  place 
between  the  constituent  systems. 

(6)  Lesson  #6:  Establish  roles  for  IPTs  and  LSIs  early  in  the  acquisition 
process. 

The  ABCS  proved  that  an  IPT  is  essential  to  the  SoS  development  process.  An 
IPT  will  have  the  perspective  to  align  constituent  systems  with  the  SoS  vision.  The  LSI 
for  the  FCS  was  established  early,  but  the  role  of  the  LSI  in  FCS  was  very  broad,  and 
seemed  to  evolve  as  the  program  developed.  The  IPTs  and  LSIs  must  have  clearly 
defined  roles  early  in  the  process  so  that  they  can  create  and  maintain  an  SoS  perspective 
throughout  the  acquisition  process.  Additionally,  if  a  private  company  assumes  the  LSI  or 
IPT  role,  there  must  be  a  government  counterpart  that  sets  the  boundaries  for  these 
private  companies.  This  will  prevent  situations  that  occurred  during  the  FCS  acquisition 
where  the  LSI  had  the  authority  to  make  major  acquisition  decisions  without  approval 
from  the  Anny. 
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(7)  Lesson  #7:  Require  top-down  management  for  a  directed  SoS. 

Generating  requirements  for  a  directed  SoS  must  be  a  top-down  process. 
Requirements  for  the  FCS  initially  focused  on  building  individual  systems.  As  the  Anny 
tried  to  integrate  systems,  it  became  evident  that  the  requirements  between  systems  were 
not  coordinated,  and  this  had  a  significant  impact  on  SoS  development.  Additionally, 
using  a  bottom-up  process  to  generate  requirements  when  you  have  several  different 
contractors  working  on  the  SoS  could  be  problematic,  because  defense  contractors  may 
show  limited  flexibility  when  it  comes  to  changing  requirements  to  accommodate  the 
SoS,  especially  if  they  feel  a  change  in  requirements  would  impact  their  bottom  line. 
Therefore,  it  is  especially  important  when  dealing  with  multiple  contractors  to  ensure  that 
the  requirements  are  generated  from  an  SoS  perspective.  This  SoS  perspective  will 
ensure  that  contractors  building  constituent  systems  keep  the  SoS  at  the  forefront  during 
acquisition  development. 

(8)  Lesson  #8:  Develop  an  SoS  architecture  early  in  the  acquisition  process. 

In  addition  to  top-down  requirements,  an  SoS  architecture  should  precede  a 
systems  architecture  in  a  directed  SoS.  In  the  case  of  the  FCS,  each  individual  new 
system  was  required  to  demonstrate  interoperability  with  all  existing  FCS  systems  before 
the  new  system  could  be  fielded.  This  resulted  in  individual  systems  spending  a  lot  of 
time  on  integration  with  previous  systems.  An  SoS  architecture  with  a  central  platform, 
or  network — such  as  on  the  ABCS — to  integrate  all  new  and  existing  systems  could  have 
saved  a  lot  of  time.  Once  a  decision  is  made  for  existing  systems  to  become  an 
acknowledged  SoS,  the  SoS  architecture  should  be  built,  and  the  constituent  systems 
must  adjust  their  individual  system  architectures  to  meet  SoS  requirements. 
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IV.  ACQUISITION  PROCESS  CHANGE  RECOMMENDATIONS 


Chapter  III  discussed  lessons  learned  from  previous  SoS  acquisitions  from  the 
Anny.  These  lessons  are  used  in  this  chapter  to  describe  processes  that  the  Army  would 
need  to  incorporate  in  order  to  apply  an  SoS  perspective  to  all  existing  and  future  Army 
programs.  The  Anny,  unlike  some  other  services,  does  not  have  a  service-specific  guide 
on  SoS  Engineering.  The  Anny  does  have  an  SoS  Engineering  and  Integration 
Directorate,  which  is  an  organization  that  primarily  deals  with  the  development  and 
implementation  of  Army  SoS.  This  organization  will  be  discussed  in  more  detail  in  the 
next  chapter,  but  many  of  the  processes  that  this  organization  deals  with  should  be 
applied  to  the  current  Army  acquisition  process  to  facilitate  an  SoS  perspective. 

The  Anny  follows  the  DOD  acquisition  process,  which  can  be  seen  in  the  diagram  in 
Figure  9. 
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IOC — initial  operational  capability 
FOC  —  full  operational  capability 
LRIP — low-rate  initial  production 
IOT&E  —  initial  operational  test  and  evaluation 
FRP  — full-rate  production 

Figure  9.  DOD  Acquisition  Process  (from  HQs  Army  2007) 


A.  CURRENT  ARMY  ACQUISITION  PROCESS 

Although  the  processes  n  Figure  9  have  been  used  to  develop  SoSs,  the  processes 
are  primarily  geared  for  developing  individual  systems.  It  should  be  noted  that  there  are 
several  intermediate  steps  involved  in  this  acquisition  process.  However,  this  chapter  will 
mainly  focus  on  the  processes  illustrated  in  Figure  9.  There  have  been  several  changes  to 
the  DOD  acquisition  process  over  the  past  several  decades,  with  the  most  recent  being  the 
Weapon  Systems  Acquisition  Refonn  Act  of  2009.  This  act  attempted  to  mitigate  the 
frequent  cost  and  schedule  overruns  that  were  prevalent  in  the  Anny  as  well  as  the  DOD. 
The  first  step  in  the  Anny  acquisition  process  is  identifying  a  user  need  based  on 
capability  gaps.  These  capability  gaps  should  be  able  to  be  traced  back  to  the  National 
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Security  Strategy,  National  Defense  Strategy,  and  the  National  Military  Strategy.  These 
gaps  are  identified  and  analyzed  through  the  JCIDS  process,  which  develops  a  capability- 
based  assessment  that  stems  from  an  integrated  architecture. 

B.  CHANGES  TO  INTEGRATED  ARCHITECTURE  DEVELOPMENT 

It  is  recommended  that  the  Anny  better  utilize  DODAF  for  current  and  future 
Anny  acquisitions,  and  apply  DODAF  to  document  the  SoS  architecture. 

One  of  the  lessons  described  in  the  previous  chapter  is  the  importance  of  an 
architectural  framework  such  as  DODAF  to  govern  the  SE  or  SoS  engineering  process. 
Greater  emphasis  needs  to  be  placed  on  this  integrated  architecture  from  an  SoS 
perspective.  The  current  requirements  for  an  integrated  architecture  suggest  that  it 
facilitates  SoS  development.  However,  as  pointed  out  in  a  thesis  by  Patrick  Hoff,  the 
integrated  architecture  refers  to  an  integration  of  multiple  perspectives  (2009)  as  opposed 
to  multiple  platforms  or  networks.  These  integrated  architectures  primarily  bring  multiple 
perspectives  to  a  single  system  rather  than  an  SoS.  Evidence  of  the  single  system 
emphasis  can  be  seen  by  examining  the  number  of  individual  programs  that  have  been 
initiated  by  the  Anny  as  opposed  to  an  SoS. 

In  2009,  for  example,  the  Army  had  twenty-one  MDAPs  in  various  stages  of  the 
acquisition  process.  Out  of  these  programs,  only  five  were  being  developed  as  part  of  an 
SoS  (Spainhower  2009).  This  includes  the  FCS,  which  was  in  the  process  of  getting 
cancelled.  The  integrated  architecture  needs  to  take  an  SoS  approach.  The  Anny  needs  to 
examine  existing  systems  and  their  capabilities,  develop  a  comprehensive  integrated 
systems  architecture  that  depicts  existing  systems,  and  explore  ways  that  these  existing 
systems  could  relate  to  one  another  from  an  SoS  perspective.  Efforts  to  integrate  systems 
from  an  SoS  perspective  have  been  explored  in  the  DOD  SE  Guidebook  (OSD  2008). 
The  Navy’s  SoS  Engineering  Guidebook  (OASN  [RDA]  2006)  also  contains  an  example 
of  an  SoS  operational  architecture  that  could  be  adopted  by  the  Anny,  as  seen  from  the 
diagram  Figure  10. 
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Figure  10.  Integrated  Architecture  Navy  SoS  (from  OASN  [RDA]  2006) 


Another  recommendation  to  accomplish  this  integrated  architecture  at  an  SoS 
level  is  the  use  of  model  based  systems  engineering  (MBSE).  As  discussed  in  the  thesis 
by  Major  Tyronne  LaStrapes  (2012),  MBSE  has  the  potential  to  reduce  the  inherent 
complexity  of  integrating  the  numerous  Army  programs  into  an  SoS  architecture. 
Applying  and  standardizing  MBSE  automation  tools  to  develop  SoS  architectures  would 
provide  an  effective  collaboration  tool  for  the  numerous  stakeholders  involved  with 
developing  and  evolving  architectures.  The  thesis  goes  on  to  say  that  the  use  of  system 
modeling  language  can  provide  a  universal  language  that  can  be  applied  to  streamline  the 
SoS  acquisition  process  (LaStrapes  2012). 
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c. 


CHANGES  TO  CONCEPT  DEVELOPMENT 


It  is  recommended  that  the  Army  formally  incorporate  a  DODAF  OV-1  for  SoS 
CONOPS  development  and  consider  adding  other  DODAF  models  as  mandatory  model 
requirements  for  the  acquisition  process. 

One  can  see  from  the  diagram  in  Figure  10  that  the  architecture  is  decomposed 
both  operationally  and  physically  by  constituent  systems.  This  decomposition  facilitates  a 
clear  understanding  of  how  the  SoS  functions  under  different  CONOPS  scenarios.  The 
Navy  also  advocates  using  several  other  DODAF  views,  such  as  the  SV-8,  System 
Evolution  Description  SV-9,  System  Technology  Forecast  TV-2,  and  Technical 
Standards  Forecast  (OASN  [RDA]  2006,  29).  These  views  can  be  applied  to  different 
phases  of  the  acquisition  process  to  facilitate  the  SoS  engineering  process.  The  Anny 
should  incorporate,  at  a  minimum,  an  OV-1  that  models  the  concepts  of  operation  that 
will  address  the  capabilities  of  the  SoS  as  a  whole.  Other  OV-ls  may  be  necessary  to 
diagram  complex  SoSs  under  different  CONOPS.  An  integrated  SoS  architecture 
analysis  should  be  incorporated  as  a  mandatory  part  of  the  acquisition  process.  Currently, 
there  is  no  requirement  for  physically  modeling  system  functions  under  different 
CONOPS  (Keenan  2013).  At  a  minimum,  the  OV-1  should  be  required  during  the  JCIDS 
process,  and  published  during  the  ICD.  Incorporating  the  OV-1  will  ensure  new 
acquisitions  are  being  examined  from  an  SoS  perspective  early  in  the  process. 

D.  CHANGES  TO  TECHNOLOGY  DEVELOPMENT  PHASE 

It  is  recommended  the  Anny  mandates  that  private  firms  demonstrate  the  ability 
for  technology  developments  to  integrate  with  an  existing  or  future  SoS.  Further,  the 
Army  should  reward  private  firms  that  demonstrate  innovative  ways  to  use  technologies 
to  integrate  existing  or  future  systems  into  an  SoS. 

A  clear  SoS  architecture  will  facilitate  the  technology  development  required  for 
the  SoS.  Currently,  the  technology  development  in  the  Defense  acquisition  system  is 
typically  outsourced  to  private  companies  to  compete  for  a  government  contract.  This  is 
evident  by  the  news  reports  of  numerous  major  defense  acquisition  programs  awarded  to 
private  firms.  Although  there  is  a  Research,  Development,  and  Engineering  Command 
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(RDECOM),  the  Army  still  contracts  a  significant  portion  of  their  R&D  to  the  private 
sector.  The  Army  typically  funds  competing  companies  to  develop  a  prototype  to  meet 
the  mission  requirements  of  the  Anny  (Angelis  2013).  The  private  firms  then  compete 
and  are  awarded  based  on  a  combination  of  factors.  These  factors  are  heavily  weighted 
on  the  technological  maturity  of  the  prototype,  and  the  cost  estimate  provided  by  the 
private  firm  (Angelis  2013).  This  process  places  an  emphasis  on  the  development  of  a 
new  technology  at  a  low  cost.  While  awarding  a  contract  based  on  these  metrics  may 
seem  to  be  the  most  efficient  process  for  the  Army,  an  SoS  approach  could  potentially 
achieve  greater  cost  savings.  For  example,  providing  an  incentive  for  private  companies 
to  integrate  existing  Army  systems  into  an  SoS  would  persuade  private  companies  to 
approach  their  technological  development  from  an  SoS  perspective.  Currently,  companies 
have  no  incentive  to  attempt  to  integrate  existing  systems.  In  fact,  private  firms  that  are 
profit  driven  generally  view  it  in  their  best  interests  to  build  a  new  system  because  of  the 
profit  potential.  Furthermore,  the  engineering  of  individual  systems  focuses  more  on  the 
optimization  of  the  individual  system.  This  does  not  necessarily  take  into  account  any 
present  or  future  requirements  that  may  make  it  necessary  to  conduct  trade-offs  at  the 
system  level  (Gansler  2009). 

As  seen  in  Chapter  III  with  the  C-RAM,  it  is  important  for  systems  to  accept 
potentially  suboptimal  system-level  performance  in  order  to  optimize  the  SoS. 
Incorporating  new  policies  that  reward  companies  for  developing  technologies  with  the 
ability  to  integrate  existing  systems  to  achieve  a  capability  will  lead  to  an  emphasis  on 
the  SoS  engineering  process.  It  will  also  mitigate  some  of  the  risks  involved  with  trying 
to  develop  brand  new  technologies.  Developing  technologies  that  facilitate  integration 
with  existing  Anny  platforms  early  in  the  acquisition  process  will  save  time  and  money. 
Therefore,  before  a  Milestone  B  approval  occurs,  private  competing  finns  should 
demonstrate  in  the  capability  development  document  (CDD)  the  ability  for  technologies 
to  be  integrated  with  existing  systems  from  an  SoS  perspective.  If  this  is  not  possible  or 
feasible,  this  should  be  explained  to  the  Milestone  decision  authority  before  the  system  is 
allowed  to  move  to  the  next  phase. 
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E.  CHANGES  TO  SYSTEM  DEVELOPMENT  AND  DEMONSTRATION 

It  is  recommended  that  all  acquisition  funding  be  initially  allocated  at  the  SoS 
level  and  divided  up  into  constituent  systems  based  on  the  each  systems’  objectives 
during  an  SoS  acquisition. 

The  CDD  approval  at  milestone  B  substantiates  the  system  as  a  program  of  record 
(POR).  Under  the  current  acquisition  system,  each  POR  has  its  own  line  of  funding.  As 
pointed  out  in  Chapter  III,  the  C-RAM  funding  was  difficult  to  track  because  each 
individual  system  had  its  own  line  of  funding.  The  acquisition  process  funding  needs  to 
better  accommodate  the  SoS.  If  the  individual  systems  maintain  their  own  line  of 
funding,  then  there  is  little  incentive  to  use  system  funding  to  meet  SoS  objectives.  Each 
SoS  should  have  a  POR  with  funding  to  cover  the  integration  of  each  constituent  system. 
There  needs  to  be  a  detailed  process  of  identifying  all  constituent  systems  and  making  an 
assessment  based  on  the  CDD  on  how  much  funding  should  be  allocated  at  the  SoS  level. 
The  importance  of  establishing  funding  lines  and  interoperability  guidelines  early  in  the 
acquisition  process  is  underscored  in  a  Carnegie  Study  referring  to  an  SoS  stating  that 
“since  the  procurement  cycles  for  both  systems  are  driven  by  their  individual 
requirements  and  funding  lines,  the  result  is  that  interoperability  is  delayed  for 
unacceptably  long  periods  of  time”  (Smith  2009,  8). 

The  consolidation  of  SoS  funding  will  pave  the  way  for  integration  and 
interoperability  early  in  the  acquisition  process.  An  SoS  POR  should  be  required  before 
the  engineering  and  manufacturing  development  phase  begins.  An  SoS  POR  will  also 
represent  a  shift  in  the  culture  of  engineering.  Engineers  and  developers  may  have  to 
sacrifice  the  performance  of  the  individual  system  to  achieve  a  greater  perfonnance  for 
the  SoS.  These  trade-offs  should  be  documented  and  presented  to  the  Milestone  Decision 
Authority  (MDA)  for  milestone  C.  The  decision  authority  for  milestone  C  should  ensure 
that  the  SoS  is  properly  scoped  before  approving  production  and  deployment.  A  lesson 
learned  from  the  FCS  and  the  ABCS  is  that  SoSs  should  understand  that  the  SoS 
engineering  is  an  iterative  process  and  100  percent  of  the  capability  may  not  be  achieved 
during  the  first  iteration.  The  program  managers  for  the  ABCS  realized  this  when  they 

determined  a  set  of  good  enough  functions  for  the  initial  fielding  of  the  system.  This  type 
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of  decision  to  reduce  the  scope  was  not  made  for  the  FCS.  The  scope  actually  expanded 
before  production  and  deployment  occurred.  Identifying  an  appropriate  scope  for  each 
iteration  of  the  SoS  development  would  allow  an  incremental  acquisition  that  achieves 
most  of  the  capability  objectives,  and  sets  the  conditions  for  future  SoS  upgrades. 

F.  CHANGES  TO  PRODUCTION  AND  DEPLOYMENT  PHASE 

It  is  recommended  that  SoSs  simultaneously  test  as  many  constituent  systems  as 
feasible  during  the  system  development  and  demonstration  phase,  and  clearly  state 
assumptions  used  during  testing.  These  assumptions  must  be  clearly  articulated  in  the  test 
plan,  and  the  test  plan  also  must  describe  the  impacts  to  the  system  if  the  assumptions  do 
not  hold  true. 

During  the  production  and  deployment  phase,  low-rate  initial  production  as  well 
as  full-rate  production  occurs  for  the  system.  This  is  also  where  system  test  and 
evaluation  (T&E)  occurs.  SoS  testing  is  challenging  when  compared  with  system  testing. 
SoS  testing  must  have  all  constituent  systems  present  to  do  a  full  SoS  test.  This  is  often 
difficult,  as  pointed  out  in  Chapter  II,  due  to  different  systems  in  different  phases  of  the 
acquisition  cycle.  SoS  testing  is  also  resource  intensive,  and  with  funding  always  being  a 
limited  resource  in  the  acquisition  process,  full  SoS  testing  usually  does  not  occur. 
Although  these  SoS  challenges  will  remain  in  the  near  future,  there  are  some  best 
practices  that  should  be  implemented  in  the  acquisition  process. 

There  must  be  a  balance  between  testing  each  constituent  system  individually  and 
testing  the  complete  SoS.  One  important  practice  is  to  clearly  articulate  the  testing  that 
will  have  to  be  simulated  due  to  funding  or  constituent  system  constraints.  Another 
important  practice  is  to  focus  testing  on  higher  risk  areas  that  have  the  most  risk  of 
degrading  the  SoS  capability  (NDIA  2012,  Slide  7).  Applying  these  testing  practices 
requires  a  solid  understanding  of  constituent  systems  and  their  relationships.  This 
understanding  can  be  achieved  by  applying  the  core  concepts  of  SoS  engineering  to  all 
SoS  systems,  and  maintaining  an  SoS  perspective  throughout  the  acquisition  process. 
Funding  for  the  SoS  testing  should  cover  the  complete  testing  of  all  individual  systems  as 
an  SoS  when  possible.  When  this  is  not  possible,  a  test  plan  should  identify  areas  where 
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simulation  is  substituted  for  portions  of  the  testing.  The  test  plan  should  quantify,  when 
possible,  the  risks  involved  with  the  simulation  and  the  assumptions  used  during  the 
simulation. 

One  of  the  problems  discussed  with  the  FCS  is  that  many  assumptions  were  used 
for  simulation  testing  that  proved  not  to  be  true.  The  SoS  test  plan  must  identify  potential 
consequences  for  a  test  assumption  not  being  true,  and  attempt  to  validate  or  invalidate 
assumptions  as  soon  as  possible.  The  decision  authority  should  take  all  of  this 
information  and  determine  whether  the  test  needs  to  wait  until  more  resources  become 
available  to  do  a  more  thorough  SoS  test,  or  plan  to  address  these  issues  in  another 
iteration  of  the  SoS,  or  accept  the  test  risks  identified  and  proceed  to  full  production 
without  making  arrangements  to  replace  simulated  tests  with  actual  tests.  This  testing 
should  be  documented  as  part  of  the  SoS  engineering  plan.  Currently,  according  to  AR 
70-1,  there  is  only  a  requirement  for  an  SE  plan,  even  for  an  SoS  (Department  of  the 
Anny  2011).  Incorporating  a  robust  T&E  plan  at  the  SoS  level  is  essential  to  the 
successful  fielding  of  an  SoS  and  should  be  part  of  the  SoS  SE  plan. 

G.  CHANGES  TO  PROGRAM  MANAGER  EVALUATION  PROCESS 

It  is  recommended  that  the  program  manager  (PM)  evaluation  process  incentivize 
the  PM’s  efforts  to  integrate  his  or  her  program  into  its  SoS  framework. 

Another  process  change  that  is  important  is  the  process  of  evaluating  program 
managers.  PMs  are  currently  evaluated  primarily  based  on  their  ability  to  develop  their 
program  within  cost  and  schedule.  The  PMs  are  normally  assigned  to  a  program  for  three 
years,  and  during  this  time  frame,  most  of  the  focus  is  on  meeting  their  program 
objectives  in  cost  and  schedule,  and  little  time  is  focused  on  interoperability  (Blanchette 
2005).  As  a  result,  there  is  less  of  an  incentive  to  incorporate  an  SoS  process  that  may 
take  funding  dollars  or  time  away  from  the  PMs  individual  programs.  The  evaluation 
process  should  change  to  incorporate  how  well  the  PM  understood  its  individual  program 
within  the  context  of  its  SoS,  and  senior  raters  should  evaluate  the  efforts  the  program 
made  to  integrate  and  achieve  interoperability  with  other  programs.  This  is  not  suggesting 
that  cost  and  schedule  requirements  should  not  be  evaluated,  but  that  the  process  change 
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should  look  at  cost  and  schedule  overruns  in  context,  and  reward  PMs  who  sacrificed 
time  and  money  on  their  individual  programs  to  accommodate  the  SoS.  Organizational 
changes  to  facilitate  this  process  will  be  discussed  in  Chapter  V. 

H.  CHANGES  TO  OPERATION  AND  SUPPORT  PHASE 

It  is  recommended  that  the  Anny  use  the  SoS  wave  model  as  an  assessment  tool 
for  SoS  architectural  evolutions,  and  future  SoS  updates. 

As  stated  in  the  second  chapter,  one  of  the  characteristics  of  SoS  is  emergence. 
During  the  operation  and  support  phase  of  the  acquisition  process,  there  needs  to  be  a 
systems  assessment  period  where  the  system  is  assessed  against  required  capabilities. 
Further,  additional  assessments  must  be  made  on  emergent  capabilities  and  risks 
identified  during  operational  use  of  the  SoS.  This  assessment  should  be  documented  and 
reviewed  before  any  SoS  upgrades  are  executed.  Assessing  the  system  at  this  stage  will 
ensure  future  SoS  upgrades  build  off  of  work  already  completed,  and  minimize  the 
duplication  of  effort  that  would  go  into  developing  a  capability  that  was  overlooked 
because  of  a  missed  emergent  trait. 

The  wave  model  should  be  used  in  conjunction  with  the  acquisition  process  to 
emphasize  the  process  changes  discussed  in  this  chapter.  It  covers  the  development  and 
evolution  of  an  SoS  architecture,  the  importance  of  testing,  and  the  importance  of  SoS 
evolvement.  Figure  1 1  is  an  illustration  of  the  wave  model. 
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Figure  11.  Wave  Model  (from  Dahmann  2012) 


This  model  should  be  used  in  conjunction  with  the  current  acquisition  process  to  facilitate 
an  SoS  approach  to  acquisitions.  The  wave  model  is  simple  but  it  emphasizes  the  iterative 
nature  of  the  SoS  acquisition  process.  The  model  focuses  on  developing  and  evolving  the 
SoS  architecture  while  planning  for  the  SoS  upgrade  and  implementation  in  parallel. 

Another  undertaking  that  should  be  incorporated  into  the  acquisition  process  from 
an  SoS  perspective  is  to  establish  PORs  to  take  existing  systems  and  integrate  them  to 
produce  capabilities  that  may  not  have  come  out  of  the  JCIDS  process.  This  also  uses  the 
concept  of  emergence  that  exists  in  SoSs.  The  acquisition  process  is  currently  a  top-down 
process,  but  understanding  individual  systems  and  their  relationships  to  one  another  may 
lead  to  a  bottom-up  process  that  explores  ways  that  existing  platforms  or  systems  can 
operate  together.  A  bottom-up  process  may  not  be  driven  by  a  capability  gap  assessment 
from  the  JCIDS;  however,  the  effort  could  provide  meaningful  capabilities  for  the  Army 
in  the  longer  term.  The  successful  integration  between  systems  will  lead  to  increased 
capabilities  for  the  Army. 
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This  chapter  has  discussed  ways  that  the  existing  Army  acquisition  process  can 
implement  an  SoS  engineering  approach  to  future  acquisitions.  Chapter  V  discusses  how 
this  SoS  approach  can  be  implemented  from  an  organizational  standpoint. 
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V.  ORGANIZATIONAL  CHANGES  TO  FACILITATE  AN  SOS 

PERSPECTIVE 


This  chapter  focuses  on  organizational  changes  that  could  facilitate  the  SoS 
process.  Changing  the  process  for  SoS  engineering  requires  simultaneous  changes  in  the 
organization  in  order  to  maintain  efficiency  and  effectiveness  (Giachetti  2010).  The 
Anny  currently  has  an  SoS  Engineering  and  Integration  directorate.  The  engineering  and 
integration  directorates  were  combined  in  2013.  This  was  a  significant  step  in 
consolidating  the  acquisition  efforts  of  Army  SoS.  However,  the  Army  acquisition 
process  is  still  very  system  focused.  Further,  efforts  to  integrate  the  SoS  engineering  and 
integration  directorate  with  the  current  Anny  acquisition  process  should  take  place  to 
facilitate  acquisitions  from  an  SoS  perspective. 

A.  CURRENT  ARMY  ORGANIZATIONAL  STRUCTURE 

The  current  organizational  chart  for  Anny  acquisition,  logistics,  and 
technology/Anny  acquisition  executive  chart  (ASAALT)  is  listed  in  Figure  12. 
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Figure  12.  ASAALT  Acquisition  Chart  (from  Carroll  2015) 
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The  SoS  Engineering  and  Integration  is  further  divided  into  current  and  future 
programs.  They  do  not,  however,  have  any  direct  control  over  the  management  of 
acquisition  systems  or  SoS.  The  Program  Executive  Officers  (PEOs)  have  the 
responsibility  of  managing  materiel  acquisitions  in  their  respective  areas.  They  can  be 
senior  officers  or  government  officials  and  they  serve  specifically  as  planning  and  budget 
authorities  for  all  programs  in  their  portfolio  (Blanchette  2005).  In  total,  the  Army  has 
twelve  PEOs.  Each  may  be  responsible  for  one,  or  several,  programs  that  fall  under  the 
PEOs  area  of  responsibility.  The  PEOs  are  responsible  for  integration  and  interoperability 
across  all  their  programs,  but  not  necessarily  integration  between  PEOs.  PEOs  use  the 
framework  developed  from  the  JCIDS  process  to  facilitate  integration  between  programs. 

B.  ROLE  OF  SOS  ENGINEERS  IN  JCIDS 

It  is  recommended  that  the  Anny  trains  and  designates  SoS  engineers  as 
mandatory  stakeholders  in  the  JCIDS  process  for  Army  acquisitions. 

As  pointed  out  in  Chapter  IV,  JCIDS  analysis  is  supposed  to  analyze  architectures 
from  a  joint  perspective  but  the  processes  and  the  funding  support  a  service-  and  PEO- 
specific  acquisition  process.  This  often  leads  to  a  system-oriented  process  that  does  not 
benefit  from  a  potential  SoS  approach.  There  must  be  Anny  SoS  representation  in  the 
JCIDS  process.  These  members  would  be  responsible  for  implementing  and 
disseminating  the  SoS  perspective  to  the  PEOs,  who  would  disseminate  this  information 
to  the  program  managers.  There  is  currently  a  gap  that  exists  between  the  JCIDS  process 
and  the  way  capabilities  are  delivered  to  the  warfighter.  A  CSIS  study  published  in  2008 
stated,  “Although  JCIDS  ‘socialized’  all  participants  into  thinking  jointly  about  capability 
needs,  the  process  did  not  define  precisely  joint  capability  gaps  or  prioritize  between 
them”  (Hicks  2008,  59).  Although  efforts  have  been  made  to  bridge  the  gap  between  the 
JCIDS  and  delivering  needed  capabilities  to  the  warfighter,  the  process  would  benefit 
greatly  from  Army  SoS  engineers  taking  part  in  the  JCIDS  process.  These  SoS  engineers 
must  have  extensive  knowledge  of  current  Army  programs  so  that  they  can  clearly 
articulate  the  SoS  framework  to  PEOs.  Further,  it  is  essential  for  these  SoS  engineers  to 
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be  involved  in  the  JCIDS  process  because  it  is  early  enough  in  the  acquisition  process  to 
get  the  full  benefit  of  SoS  Engineering. 


C.  ROLE  OF  THE  CHIEF  INTEROPERABILITY  OFFICER 

It  is  recommended  that  a  Chief  Interoperability  Officer  be  assigned  to  all  future 
Anny  acquisitions  early  in  the  process.  This  officer  will  be  the  authority  on  all 
interoperability  issues,  and  ensure  that  interoperability  objectives  are  met  in  the  JCIDS 
process. 

One  of  the  issues  that  Army  PEOs  have  identified  with  the  acquisition  process  is 
the  lack  of  understanding  of  interoperability.  In  an  interview  conducted  with  several 
PEOs,  one  of  the  common  themes  was  that  program  managers  did  not  understand 
interoperability.  PEOs  often  stated  that  program  managers  viewed  interoperability  as  a 
cost  line  and  did  not  understand  how  to  implement  it  within  the  context  of  their  program 
(Blanchette  2005).  Further,  interoperability  across  programs  is  a  PEO  responsibility,  but 
there  is  no  requirement  for  interoperability  between  PEOs.  As  a  result,  there  are  PEOs 
trying  to  get  program  managers  to  become  interoperable  across  programs  when  they  do 
not  clearly  understand  what  needs  to  be  done  in  order  to  achieve  this  interoperability. 
Blanchette  (2005)  observes  that  several  PEOs  believe  that  this  confusion  stems  from  a 
lack  of  central  authority  on  interoperability  issues.  The  report  states: 

However,  several  PEOs  identified  the  need  for  “one  trail  boss,”  that  is,  a 
central  authority  with  the  broader  perspective  on  interoperability.  One 
PEO  suggested  that  this  authority  should  reside  at  the  Department  of 
Anny  or  Joint  Services  level.  (11) 

This  suggests  that  an  authority  on  interoperability  would  be  beneficial  to  the 
acquisition  process.  They,  along  with  a  staff,  can  set  the  interoperability  guidelines  for 
each  SoS  program.  Additionally,  this  interoperability  authority  could  mitigate  some  of 
the  challenges  associated  with  demonstrating  a  net-readiness  capability  as  required  by  the 
JCIDS  process.  This  could  prevent  incidents  like  the  FCS  discussed  in  Chapter  III.  In  this 
case,  interoperability  was  a  requirement  for  a  new  system  to  be  built,  but  there  were  no 
specific  guidelines  on  how  the  interoperability  would  occur.  The  FCS  seemed  to 
approach  interoperability  as  an  individual  system  responsibility  as  each  system  was  built, 
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rather  than  starting  with  an  interoperability  plan  and  building  each  system  in  accordance 
with  the  plan.  An  interoperability  authority  in  the  JCIDS  process  could  mitigate  some  of 
the  problems  that  occurred  during  the  FCS  acquisition  process. 

D.  ROLE  OF  THE  LEAD  SYSTEM  INTEGRATOR 

It  is  recommended  that  the  Anny  train  personnel  in  order  to  make  the 
organizational  role  of  LSI  a  government  function,  or  at  a  minimum  oversee  private 
companies  that  assume  this  role. 

Another  issue  relating  to  interoperability  deals  with  the  LSI  concept  that  was  used 
to  develop  the  FCS.  One  of  the  issues  with  this  concept  is  that  integration  and 
interoperability  was  left  up  to  the  contractors,  with  little  government  oversight.  This  was 
the  case  with  the  FCS,  where  Gansler  (2009)  states: 

LSIs,  however  have  been  given  broad,  government-like  authority  to 
execute  acquisition  programs  that  include  development  of  individual 
system  requirements,  contracting  for  their  development  and  procurement, 
and  coordination  of  development  schedule  and  efforts,  (vii) 

The  research  paper  goes  on  to  say  that  the  reason  the  government  relies  so  heavily  on  the 
LSI  contractor  is  the  lack  of  organic  expertise  in  the  government  when  it  comes  to  SoS 
Engineering,  interoperability,  and  integration  (Gansler  2009).  It  is  important  that  the 
government  invests  in  the  personnel  that  are  capable  of  understanding  the  role  of  the  LSI. 
This  would,  at  a  minimum,  provide  oversight  to  the  LSI  contractors  if  the  government 
chooses  to  contract  the  LSI  job.  Ideally,  the  government  would  have  the  organic 
capability  to  perform  as  an  LSI  for  SoS  programs.  The  Anny  currently  has  organizations 
that  can  foster  the  knowledge  required  for  an  LSI.  For  example,  RDECOM  has  several 
organizations  that  cover  a  wide  spectrum  of  Army  functions  and  future  capabilities. 
RDECOM  can  be  used  to  train  LSIs  for  SoS  acquisitions.  Additionally,  expanding  the 
SoS  engineering  and  integration  directorate  is  another  option  to  acquire  the  necessary 
expertise  to  perfonn  LSI  functions.  Trained  LSIs  in  DOD  will  limit  the  authority  that  the 
defense  contractors  have  with  regard  to  LSIs.  These  companies  are  profit  driven  as 
opposed  to  process  driven.  Using  LSIs  from  the  government  will  help  facilitate  the  SoS 
engineering  process  during  SoS  acquisitions. 
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E.  ROLE  OF  THE  CAPABILITY  PORTFOLIO  MANAGER 

It  is  recommended  that  capability  portfolio  managers  be  assigned  at  the  PEO 
level,  and  that  current  and  future  SoS  acquisitions  are  organized  based  on  the  capability 
manager’s  area  of  responsibility  as  opposed  to  the  PEOs. 

Another  organizational  change  that  would  benefit  the  acquisition  of  systems  from 
an  SoS  perspective  is  the  implementation  of  capability  portfolio  managers.  The  Anny 
currently  assigns  TRADOC  capability  managers  (TCMs)  to  programs.  These  TCMs  are 
assigned  as  TRADOC  counterparts  to  program  managers.  They  are  primarily  responsible 
for  incorporating  all  doctrine,  organization,  training,  leadership,  education,  personnel, 
and  facilities  (DOTMLPF)  (Keenen  2013).  Assigning  TCMs  with  the  PMs  ensure  that  the 
individual  program  addresses  capabilities  across  the  Anny’s  functional  domains; 
however,  these  capability  managers  are  not  an  integral  part  of  the  JCIDS  process  that 
decides  what  materiel  solutions  to  develop.  As  a  result,  the  TCMs  are  part  of  materiel 
development  but  not  involved  in  the  decision  process  that  initiates  the  materiel 
development.  Capability  managers  should  also  be  used  on  a  macro  level  to  facilitate  the 
SoS  acquisition  process.  These  capability  managers  should  be  assigned  as  counterparts  to 
the  PEOs  along  with  the  TCMs  that  are  counterparts  at  the  program  level.  Figure  12 
describes  the  current  organization  of  PEOs,  but,  as  stated  earlier,  this  does  not  facilitate 
the  interoperability  and  integration  required  at  the  SoS  level.  Table  4  is  from  a  RAND 
dissertation  that  lists  eleven  of  the  Force  Operating  Capabilities  (FOC)  that  the  Army 
uses  to  categorize  systems.  Currently,  there  are  no  capability  managers  at  this  level. 
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Table  4.  Eleven  Army  FOCs  (as  cited  in  Hiromoto  2013,  10) 


# 

FOC 

Example  1 

Example  2 

1 

Batde  Command 

Command  and  control 

Decision  superiority 

2 

Batdespace  Awareness 

Intelligence  information 

Manage  knowledge 

3 

Mounted/Dismounted  Maneuver 

Mobility 

Urban  operations 

4 

Air  Maneuver 

Aviation  support 

Reconnaissance 

5 

Lethality 

Precision 

Automated  fire 

6 

Maneuver  Support 

Understand  battle  space 

Freedom  of  maneuver 

7 

Force  Protection 

Personnel  protection 

Asset  protection 

8 

Responsiveness  /  Deployability 

Airlift  /  sealift 

Theater  access 

9 

Maneuver  Sustainment 

Power  and  energy 

Force  health 

10 

Training,  Leadership,  Education 

Leadership  training 

Unit  performance 

if 

Human  Engineering 

Reduce  soldier  load 

Decrease  task  complexity 

Source:  Mackay  (2008) 


Using  capability  managers  at  this  level  will  facilitate  clearer  boundaries  with 
regards  to  funding  lines.  One  of  the  issues  with  SoS  development,  as  noted  earlier,  is  the 
often  nebulous  funding  lines.  The  C-RAM,  for  example,  had  difficulty  determining  how 
much  money  was  spent  on  C-RAM  efforts  as  opposed  to  individual  system  efforts. 
Additionally,  Capability  Set  13  (CS13)  is  currently  under  the  PEO  C3-T,  but  integration 
efforts  would  likely  incorporate  PEOs  from  the  GCS  and  the  Soldier  because  the 
communication  systems  will  be  used  and  tested  with  equipment  outside  of  the  PEO  C3Ts 
area  of  responsibility.  The  fact  that  CS13  potentially  incorporates  systems  from  several 
PEOs  underscores  the  importance  of  establishing  funding  at  the  SoS  level.  Using 
capability  managers  at  the  PEO  level  and  aligning  the  funding  with  the  PEO  managers 
could  provide  a  way  to  fund  and  budget  SoS  acquisition  programs.  Another  added  benefit 
of  having  capability  managers  at  the  PEO  and  program  levels  is  that  it  could  facilitate 
bottom-up  SoS  engineering.  As  alluded  to  in  Chapter  IV,  SoS  and  systems  engineering  is 
focused  on  a  top-down  approach,  however,  a  bottom-up  approach  of  the  existing  systems 
to  better  align  them  with  an  SoS  would  be  beneficial  when  designing  a  baseline  SoS 
architecture.  According  to  Hiromoto  (2013),  in  2006  there  were  104  individual  systems 
that  supported  the  Lethality  and  Force  Protection  FOCs.  Table  5  identifies  functional 
categories  within  the  FOCs  that  had  five  or  more  individual  systems. 
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Table  5.  Lethality  and  Force  Protection  Categories  with  Five  or  More 

Systems  (from  Hiromoto  2013) 


Function 

Number  of  Systems 

Air  Defense 

7 

Anti-IED 

10 

Artillery 

5 

Ground  Vehicles 

5 

Missiles 

12 

Small  Arms 

7 

Targering/  Queuing 

6 

Uniforms  &  Clothing 

6 

Vision  &c  Weapon  Sights 

5 

Source:  Calculated  from  R2  Budget  Item  Justification  Sheets 


Using  capability  managers  at  the  program  level  in  conjunction  with  capability 
managers  at  the  PEO  level  will  facilitate  the  bottom-up  analysis  that  is  necessary  to  create 
an  SoS  architecture  for  a  number  of  these  individual  systems  that  fall  under  the  same 
functional  category. 

Adding  personnel  to  the  JCIDS  process  or  the  acquisition  process  may  seem  like 
there  is  another  level  of  added  bureaucracy  to  a  system  that  already  takes  years  to 
produce  complete  systems.  However,  as  suggested  in  the  RENO  report  conducted  in 
2009,  which  was  referenced  in  a  thesis  written  by  LTC  Douglas  Cherry  (2010),  the  Army 
should  look  at  eliminating  stovepipe  organizations  in  the  G3/5/7.  These  organizations 
contribute  to  a  system  perspective  rather  than  an  SoS  perspective,  and  they  are  a  part  of 
the  JCIDS  process.  The  report  specifically  mentions  organizations  such  as  “Aviation 
(DAMO-AV),  Biometric  Task  Force  (BTF),  Army  Asymmetric  Warfare  Office 
(AAWO),  Electronic  Warfare  (EW),  and  LANDWARNET/Battle  Command  (LB)” 
(Cherry  2010,  12).  LTC  Cherry  goes  on  to  suggest  replacing  these  organizations  with  a 
capabilities  and  combined  arms  directorate.  Although  this  study  was  conducted  in  2009, 
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many  of  these  organizations  still  exist  in  the  Army  in  2015.  The  Anny  should  take  a  look 
at  these  organizations  and  eliminate  the  ones  that  do  not  contribute  to  an  SoS  approach  to 
acquisitions. 


F.  CHAPTER  SUMMARY 

This  chapter  has  discussed  potential  organizational  changes  that  could  facilitate  an 
SoS  engineering  approach  to  current  and  future  acquisitions.  First,  the  Anny  should  have 
an  SoS  engineer  as  part  of  the  JCIDS  process  to  ensure  that  there  is  an  understanding 
from  the  beginning  of  the  process  on  how  the  new  acquisition  fits  into  the  greater  SoS 
architecture.  Further,  the  Anny  needs  to  have  organic  personnel  that  can  perform  or 
oversee  the  role  of  LSI  so  the  Army  does  not  empower  the  contractors  too  much  during 
the  SoS  process.  The  FCS  is  an  example  of  an  LSI  having  too  much  authority.  The  Army 
also  needs  to  expand  the  role  of  the  capability  manager  to  the  PEO  level,  and  align 
funding  based  on  the  eleven  major  FOCs  as  opposed  to  the  PEOs.  Finally,  the  Anny 
should  look  at  all  stove-piped  organizations  that  cunently  take  part  in  the  JCIDS  process 
and  consolidate  them  into  a  combined  arms  or  capabilities  directorate. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  purpose  of  this  research  was  to  explore  the  idea  of  approaching  future 
acquisitions  from  an  SoS  perspective.  This  would  require  SoS  Engineering  to  take  place 
as  well  as  process  and  organizational  changes  to  facilitate  this  culture  shift.  The  study 
began  with  a  brief  history  of  the  evolution  of  the  Army  acquisition  process  that  led  to  an 
increase  focus  on  SoS  programs.  The  thesis  then  discussed  the  major  steps  of  the  Army’s 
current  acquisition  process.  The  study  then  focused  on  addressing  the  following  research 
questions: 

1 .  What  are  some  of  the  lessons  learned  and  best  practices  that  can  be 
gleaned  from  the  Anny’s  past  attempts  at  SoS  acquisitions? 

2.  What  current  processes  in  the  Anny  acquisition  system  should  change,  be 
created,  or  be  implemented  as  policy  in  order  to  facilitate  systems 
engineering  from  an  SoS  perspective? 

3.  What  organizational  changes  in  the  Anny  need  to  take  place  to  facilitate  a 
successful  SoS  engineering  process? 

The  literature  review  discussed  pertinent  definitions  regarding  systems 
engineering  and  SoS  engineering.  It  went  on  to  discuss  the  systems  engineering  process 
in  acquisitions,  the  SoS  engineering  model,  and  the  core  elements  of  SoS  engineering. 
The  third  chapter  examined  three  previous  SoS  acquisitions  by  the  Anny,  and  analyzed 
these  acquisitions  using  the  core  elements  of  SoS  engineering.  Using  the  lessons  learned 
from  these  three  programs,  Chapter  IV  discussed  some  of  the  process  changes  that  would 
facilitate  an  SoS  approach  to  future  acquisitions.  The  following  chapter,  building  on  the 
lessons  learned  in  Chapter  III,  and  the  process  changes  from  Chapter  IV,  discussed 
organizational  changes,  specifically  personnel  changes  that  would  facilitate  an  SoS 
engineering  approach  to  acquisitions. 
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A. 


FINAL  CONCLUSIONS 


The  results  of  this  study  suggest  that  an  SoS  engineering  approach  to  future  Anny 
acquisitions  is  not  only  possible,  but  necessary.  The  Anny  is  part  of  a  joint  force  with 
systems  that  will  become  increasingly  connected.  The  military  is  currently  divided  into 
Combatant  Commands.  The  Combatant  Commanders  (COCOM)  have  the  great 
responsibility  of  managing  any  conflict  within  their  region.  COCOMs  lead  a  diverse 
group  of  forces.  A  COCOM  commander  has  personnel  and  equipment  from  all  military 
branches,  but  currently  the  acquisition  process  is  set  up  so  that  each  branch  conducts  its 
own  acquisitions,  and  within  the  branches,  each  PEO  is  responsible  for  acquisitions  in  his 
or  her  domain.  As  a  result  of  this  process,  COCOMs  often  get  redundant  systems  fielded 
between  services,  as  well  as  redundant  systems  within  the  services.  Currently,  the 
acquisition  process  does  not  align  with  how  the  military  is  task  organized  to  fight  and  win 
wars.  Using  an  SoS  approach  with  SoS  engineering  principles  would  be  the  first  step  for 
the  Anny  to  align  itself  with  the  way  the  military  is  set  up  to  fight  wars.  The  next  step 
would  be  implementing  this  SoS  approach  in  a  joint  environment  that  incorporates  all  the 
military  services. 

An  SoS  approach  does  not  mean  that  individual  system  engineering  principles  and 
practices  are  obsolete.  Developing  individual  systems  will  still  be  important  and 
necessary.  The  difference  with  an  SoS  approach  is  that  the  greater  system  will  always  be 
at  the  forefront  when  new  acquisitions  take  place.  This  means  that  even  as  the  systems 
engineering  for  an  individual  system  is  being  conducted,  the  individual  system  should 
complement  the  SoS  engineering  that  is  being  done  to  the  SoS. 

The  transition  from  a  system-based  to  an  SoS-based  acquisition  will  take  a  lot  of 
effort.  Understanding  the  relationships  between  a  system  and  its  SoS  will  require 
significant  coordination  and  flexibility.  Some  of  the  process  changes  recommended  will 
require  a  cultural  shift  from  the  way  the  Anny  has  been  acquiring  systems.  For  example, 
the  integrated  architecture  that  incorporates  DODAF  views  in  the  ICD  will  require  SoS 
engineers  who  have  a  complete  understanding  of  constituent  systems  and  their 
relationships.  It  will  also  force  designers  to  think  about  future  systems  when  designing 

and  building  a  particular  SoS  iteration.  Engineers  that  are  used  to  optimizing  individual 
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systems  will  have  to  operate  in  trade  space  and  potentially  build  a  system  sub-optimally 
for  the  greater  good  of  the  SoS.  Additionally,  the  way  the  acquisition  force  is  trained  will 
also  have  to  change.  The  acquisition  force  must  develop  capability  managers  who  can 
provide  macro  level  management  of  capabilities  in  their  FOCs.  These  trained  capability 
managers  can  assist  in  providing  a  better  method  of  funding  and  cost  accounting  for  SoS 
acquisitions.  Currently,  there  is  not  much  of  an  incentive  for  program  managers  to 
sacrifice  for  the  SoS  because  program  managers  are  focused  on  delivering  their  product 
within  cost  and  schedule.  Changing  the  funding  to  align  with  SoS  acquisitions  will 
encourage  program  managers  to  approach  their  programs  from  an  SoS  perspective. 

Perhaps  the  most  important  part  of  this  cultural  shift  is  education  for  the  future 
acquisition  workforce.  The  Army  has  substantial  training  on  the  acquisition  process,  and 
systems  engineering  within  the  acquisition  process,  however,  SoS  engineering  is  not 
emphasized  in  training  the  future  acquisition  force.  The  Anny  needs  to  incorporate  SoS 
training  in  acquisitions.  The  Anny  has  taken  steps  to  incorporate  SoS  by  establishing  an 
SoS  engineering  and  integration  directorate.  This  directorate  has  already  been  beneficial 
to  SoS  programs  that  have  leveraged  their  expertise.  The  Army  should  build  off  of  this 
expertise  and  look  into  incorporating  some  of  the  process  and  organizational  changes  that 
will  facilitate  an  SoS-approach  to  future  Anny  acquisitions. 

B.  RECOMMENDATIONS  FOR  FUTURE  STUDY 

There  is  significant  opportunity  for  further  research  on  this  study.  This  research 
examined  three  SoS  programs  that  the  Anny  conducted.  There  are  several  other  lessons 
learned  from  other  SoS  programs  that  were  not  covered.  There  are  also  important  lessons 
learned  that  could  be  gained  from  studying  individual  systems  acquisitions.  This  study 
examined  MDAP  acquisition,  but  there  are  also  several  smaller  programs  that  could 
benefit  from  a  study  of  how  the  smaller  individual  systems  would  fit  into  a  larger  SoS 
framework.  These  smaller  programs  that  don’t  classify  as  MDAPs  seem  to  receive  less 
attention  because  of  their  lower  costs.  This  research  recommends  process  changes  to  the 
major  steps  of  the  acquisition  process;  however,  a  more  in-depth  look  at  some  of  the 
underlying  processes  in  the  acquisition  system  should  also  be  examined  for  potential 
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changes.  Additionally,  a  feasibility  study  on  the  proposed  changes  recommended  in  this 
study,  as  well  as  any  future  changes  suggested,  would  be  beneficial  before  these 
processes  were  implemented  in  the  acquisition  process.  Furthermore,  this  study  did  not 
benefit  from  any  specific  firsthand  accounts  of  the  acquisition  process  from  acquisition 
professionals,  or  key  members  of  the  acquisition  community.  Further  research  should 
incorporate  interviews  from  PEOs,  PMs,  and  other  personnel  on  their  personal 
experiences  with  system  or  SoS  acquisitions. 
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